Bundesamt 

fiir Sicherheit in der 

Informationstechnik 



Sicherheit von Webanwendungen 
MaBnahmenkatalog und Best Practices 



Im Auftrag des 

Bundesamtes fiir Sicherheit 
in der Informationstechnik 

erstellt von: 

O SecureNet 



Version 1 , August 2006 



Bundesamt fiir Sicherheit in der Informationstechnik 



Godesberger Allee 185-189, 53175 Bonn • Postfach 200363. 53133 Bonn 
Tel.: 01888 9582-0 ■ -t-49 (0)3018 9582-0 
Fax:01888 9582-5400 ■ +49(0)30189582-5400 
Internet: www.bsi.bund.de 



Bundesamt fur Sicherheit SecureNet GmbH 

in der Informationstechnik Miinchner Technologiezentrum 

Postfach 20 03 63 Frankfurter Ring 193a 

53133 Bonn 80807 Miinchen 

www.bsi.bund.de www.securenet.de 

© BSI Thomas Schreiber 

Achim Hoffinann 



Bundesamt fur Sicherheit in der Informationstechnik 



2 



Sicherheit von Webanwendungen 



Summary 

Der vorliegende MaBnahmenkatalog stellt SchutzmaBnahmen und Best Practices zur 
Vorbeugung gegen typische Schwachstellen in Webanwendungen bereit. Ein voran- 
gestellter Leitfaden gibt Hinweise fiir ein systematisches Vorgehen zur Erstellung si- 
cherer Webanwendungen. Dabei werden sowohl bereits bestehende, als auch neu zu 
entwickelnde Webanwendungen betrachtet. 

Der MaBnahmenkatalog richtet sich an Projektleiter und Softwareentwickler, die Web- 
anwendungen konzipieren und implementieren. 
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Einleitung 

Browser und Web sind heute allgegenwartig. Nicht nur im Consumer-Bereich ist das 
Web unverzichtbares Medium fur eine Vielzahl von Anwendungszwecken geworden. 
Auch Geschaftsprozesse zwischen Geschaftspartnem (B2B) sowie zwischen Burger 
und Behorde (E-Government) werden immer starker im Web abgewickelt. Die 
Spannweite reicht von einfachen Anwendungen wie der Suche nach Produktinforma- 
tionen oder dam Bezug von Formularen, iiber Auktionen, bis hin zu Produktbestel- 
lung, Internet-Banking oder Abwicklung von Ausschreibungen, und nicht zuletzt 
dem Zugang ins untemehmenseigene Intranet. 

Angetrieben wird diese rasante Entwicklung von den enormen Moglichkeiten, Ge- 
schaftsprozesse zu vereinfachen, zu beschleunigen und deren Produktivitat zu erho- 
hen. Die Nutzung des Web fiihrt zu Kosteneinsparungen, verschafft Wettbewerbsvor- 
teile und eroffhet neue Geschaftsfelder. 

Im Bestreben, diese Vorteile bestmogUch zu nutzen, werden die Augen vor den Risi- 
ken all zu haufig verschlossen: Methoden, die sich in anderen Bereichen der Informa- 
tionstechnologie bewahrt haben, werden ohne ihre Eignung und ihre Sicherheit zu 
hinterfragen ins Web ubemommen; sensible Daten und Verbindungen zum Backend 
werden ohne zusatzliche Sicherungen iiber das Web zuganglich gemacht - haufig in 
der Annahme, der erforderliche Schutz sei durch die Netzwerk-Firewall gegeben; 
Webanwendungen werden in den Produktivbetrieb ubemommen, ohne dass sie stran- 
ge Qualitatskontrollen in Bezug auf Sicherheitseigenschaften durchlaufen miissen; 
untemehmenskritische Geschaftsprozesse werden direkt auf das Web abgebildet, 
ohne ihre Angreifbarkeit zu untersuchen und SchutzmaBnahmen vorzunehmen. 

Dabei stellt gerade das Web besonders hohe und im Vergleich zu anderen Bereichen 
der IT ganz spezielle Anforderungen an die Sicherheit: 

• Die Offenheit des Web macht eine Webanwendung nicht nur fiir den legitimen 
Benutzer miihelos zuganglich, sondem potentiell auch fur jeden nicht-legitimier- 
ten "Interessenten" erreichbar. 

• Technologien wie Firewalls, die Schutz vor Angriffen an zentraler Stelle herstel- 
len, sind auf der Ebene des Web in Form so genannter WebShields oder Applica- 
tion Firewalls zwar mittlerweile auch verfiigbar, kommen aber in der Starke des 
Schutzes den Firewalls nicht gleich und werden gegenwartig noch wenig einge- 
setzt. 

• Das Web bietet eine Reihe von Moglichkeiten, anonjmi zu agieren. Das Risiko 
eines Angreifers ist daher gering und die Hemmschwelle entsprechend niedrig. 
Hinzu kommt, dass Angriffe im Web oflmals weniger Vorkenntnisse erfordem 
als auf der Netzwerkebene. 

• Das Web ist in vielen Fallen direkter Umsatztrager und hat dann einen groBen 
Einfluss auf den Geschaftserfolg eines Untemehmens. So steht die Forderung ei- 
ner moglichst uneingeschrankten Nutzung im standigen Zielkonflikt mit den Er- 
fordemissen der Sicherheit. 

• Wegen seiner einfachen Zugangsmoglichkeiten wird das Web auch von Anwen- 
dem genutzt, die nicht die erforderUchen Kenntnisse besitzen, um sich angemes- 
sen zu schiitzen. 
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Im Zuge von Konzeption und Implementierung von Webanwendungen wird Sicher- 
heitsaspekten vielfach nur unzureichende Beachtung geschenkt: Richtlinien zur si- 
cheren Programmierung warden nicht vorgegeben oder beachtet; Freigabeprozesse, 
die vor der Produktivschaltung ein definiertes Sicherheitsniveau herstellen wiirden, 
existieren nicht; generell verfugbare SchutzmaBnahmen werden zugunsten maximaler 
Verfiigbarkeit und Kostenerspamis nicht angewandt. Und schlieBlich: Softwareent- 
wicklungs-Vertrage und -Budgets sehen die Sicherheit der Anwendung als Teilaspekt 
des Gesamtprojektes oft nicht vor. 

Die vorliegende Zusammenstellung von Best Practices enthalt vielfach erprobte MaB- 
nahmen zur Herstellung sicherer Webanwendungen. Sic soil technisch orientierten 
Lesem, insbesondere auch Softwareentwicklem als Anleitung und zum Nachschlagen 
dienen. 

Der Themenbereich "Sicherheit von Webanwendungen" wird in einem 5-Ebenen- 
Modell dargestellt. Dieses enthalt neben der Systemebene, der Technologieebene und 
der Implementierungsebene auch die Ebenen der Anwendungslogik und der Seman- 
tik. Die beiden letzteren Ebenen sind dabei in der Regel bei der verantwortlichen 
Fachstelle angesiedelt, so dass sich der MaBnahmenkatalog auch an Projektleiter im 
Bereich Webanwendungen richtet. 

Auch wenn der MaBnahmenkatalog nicht als umfassende Anleitung fur ein Sicher- 
heitsaudit einer Webanwendung gedacht ist, kann er auch hierfur ein gutes Stiick weit 
genutzt werden. 

Wahrend in Kapitel 1 ein Leitfaden zur systematischen Erstellung sicherer Weban- 
wendungen vorgestellt wird, befindet sich in Kapitel 2 die Zusammenstellung der 
EinzelmaBnahmen. 

Auf eine detaillierte Beschreibung von Schwachstellen wird bewusst verzichtet. Hier- 
fiir wird der Leser auf Quellen im Internet verwiesen. 
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1 Leitfaden zur Sicherheit in Webanwendungen 

In diesem Kapitel wird eine Anleitung zur Erstellung von sicheren Webanwendungen 
vorgestellt. Die hierfiir angefuhrten allgemeinen Schritte und Hinweise miissen dabei 
im Rahmen einer konkreten Anwendung durch projektspezifische Erfordemisse er- 
ganzt und detailliert werden. Hierzu konnen z.B. zahlen: Architekturfragen, software- 
technische Randbedingungen wie Technologie und Programmiersprache, individuelle 
Anforderungen einer Webanwendung oder Website, bestehender Finanzrahmen oder 
auch individuelle Prozesse fur Entwicklung und Betrieb einer Anwendung. Wenn- 
gleich diese genannten Teilaspekte im Rahmen eines konkreten Projektes eine wichti- 
ge RoUe spielen, wird der Fokus hier - auch mit Blick auf eine notwendige Abgren- 
zung des Themengebietes - auf eine systematische Darstellung organisatorischer und 
technischer SchutzmaBnahmen gelegt. 

In Hinblick auf teilweise enge Abhangigkeiten und Wechselwirkungen zwischen Si- 
cherheitsaspekten in Webanwendungen und anderen Bereichen der IT-Sicherheit 
wird fiir eine organisatorische Zuordnung der fiir Webanwendungen relevanten Teila- 
spekte hier ein Ebenenmodell vorgestellt. Dieses Ebenenmodell wird zunachst kurz 
im nachfolgenden ersten Teilkapitel erlautert. 

Ein genereller Unterschied im Losungsansatz ergibt sich aus der Fragestellung, ob 
eine bereits bestehende oder eine neu zu entwickelnde Webanwendung betrachtet 
wird. Hieraus resultiert eine getrennte Beschreibung im zweiten und dritten Teilkapi- 
tel des Leitfadens. 
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1.1 Ebenenmodell zur Sicherheitskonzeption von 
Webanwendungen 

Auf Grundlage eines Ebenenmodells lassen sich die Zustandigkeiten der relevanten 
Organisationsbereiche den einzelnen Teilaufgaben bei Sicherheitskonzeption und 
Realisierung von Webanwendungen zuordnen. Ausgangspunkt ist eine Unterteilung 

in 5 Ebenen: 



Ebene 


Inhalt (Beispiele) 


5 


Semantik 


Schutz vor Tauschung und Betrug 

- Infonnationen ermoglichen Social Engineering- Angriffe 

- Gebrauch von Popups u.a. erieichtem Phishing-Angriffe 

- Keine Absicherung fiir den Fall der Falschung der Web- 
site 


4 


Logik 


Absicherung von Prozessen und Workflows als Ganzes 

- Verwendung unsicherer Email in einem ansonsten gesi- 
cherten Workflow 

- Angreifbarkeit des Passworts durch nachlassig gestaltete 
"Passwort vergessen"-Funktion 

- Die Verwendung sicherer Passworte wird nicht erzwun- 
gen 


3 


rung 


Vemieiden von Programmierfehlem, die zu Schwachstellen 

fiihren 

- SQL-Injection 

- Session Riding 


2 


Technologic 


Richtige Wahl und sicherer Einsatz von Technologic 

- unverschliisseltc Ubertragung sensitiver Daten 

- Authentisierungsverfahren, die nicht dem Schutzbedarf 
angemessen sind 

- Ungenugende Randomness von Token 


1 


System 


Absicherung der auf der Systemplattform eingesetzten 
Software 

- Fehler in der Konfiguration des Webservers 

- "Known Vulnerabilities" in den eingesetzten Software- 
produkten 

- Mangelnder Zugriffsschutz in der Datenbank 


0 


Netzwerk & 
Host 


Absicherung von Host und Netzwerk 


AbbiW 


ung 1: Ebenenmodell 
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Ebene 0 - Netzwerk und Host 

Die Ebene von Netzwerk, Server-Hardware und darauf laufendem Betriebssystem 
wird hier nicht direkt der Sicherheit der Webanwendung zugeordnet. Diese Ebene 
schlieBt sich vielmehr nach unten an. Die Umsetzung grundlegender SicherheitsmaB- 
nahmen auf dieser Ebene wird gleichwohl als zwingende Voraussetzung fur sichere 
Webanwendungen betrachtet. 

Ebene 1 - Systemebene 

Hier werden all jene Programme betrachtet, die fiir das Funktionieren der gesamten 
Webanwendung benotigt werden. Dazu gehoren der Webserver und der Applikati- 
onsserver, aber auch Datenbank- und Backend-Systeme. Diese Komponenten miissen 
bei der Sicherheitskonzeption einer Webanwendung mit einbezogen werden. 

Ebene 2 - Technologie 

Diese Ebene betrifft die Verwendung der fiir den jeweiligen Einsatzzweck und 
Schutzbedarf richtigen Technologie, sowie deren korrekte Nutzung. So z.B. setzt eine 
Webanwendung, die sensible Daten unverschliisselt iiber das Internet transferiert, 
nicht die richtige Technologie ein. Eine Webanwendung, die Passworte zwar ver- 
schliisselt, dafur aber einen zu kurzen Schliissel verwendet, setzt die richtige Techno- 
logie falsch ein. 

Ebene 3 - Implementierung 

Die Implementierungsebene umfasst den Bereich der unbeabsichtigten Programmier- 
fehler (Bugs), aber auch nicht vorhandene oder ungeniigende Priifung von Eingabe- 
daten ("Data Validation"). Diese Ebene beinhaltet femer ungeniigende Testverfahren, 
und die Vemachlassigung der Qualitatssicherung zugunsten des Inbetriebnahmeter- 
mins oder aus Kostengriinden. 

Ebene 4 - Logik 

Diese Ebene betrifft sowohl die Logik der Ablaufe innerhalb einer Webanwendung, 
als auch die Interaktion mit dem Benutzer. 1st diese zu 'zweckorientiert' implemen- 
tiert, kann gegebenenfalls eine Missbrauchsmoglichkeit vorliegen. Wird etwa zur 
Verhinderung einer mehrfach wiederholten Eingabe eines Passwortes nach dem funf- 
ten fehlerhaften Loginversuch die entsprechende Benutzerkennung gesperrt, so konn- 
te dieser Benutzer durch Dritte gezielt ausgesperrt werden, sofem keine weiteren 
MaBnahmen getroffen werden. Diese missbrauchliche Vorgehensweise wird weiter 
erleichtert, wenn die Benutzerkennung einfach zu erraten ist. 

Ebene 5 - Semantik 

Die semantische Ebene umfasst inhalts- und kommunikationsbezogene Aspekte. Sie 
stellt den Vertrauenskontext fiir die Interaktion mit einem Benutzer her. Wird in die- 
sem Bereich nicht ein hohes MaB an Sorgfalt aufgewendet, so kann eine Webanwen- 
dung von Dritten missbraucht werden, um einen Benutzer zu tauschen. Dieser Be- 
reich kann selten auf eine einzelne Anwendung beschrankt bleiben. Vielmehr ist eine 
website- oder untemehmensiibergreifende Betrachtung notwendig. Missbrauchsmog- 
lichkeiten, die sich Fehler auf der semantischen Ebene zunutze machen, sind Social 
Engineering, Phishing, Identitatsdiebstahl u.a. 

Die Bedeutung der logischen und semantischen Ebene wird vielfach nur unzurei- 
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chend wahrgenommen. Dennoch haben diese beiden Ebenen eine hohe Bedeutung, 
werin man unter der Sicherheit einer Webanwendungen nicht allein nur den Schutz 
des Servers versteht, sondem eine umfassende Perspektive zugrunde legt: Der Anbie- 
ter einer Webanwendung tragt nicht nur Verantwortung fur eigene Systeme, sondem 
auch fur alle an der Nutzung der Webanwendung Beteiligten. Auf der Ebene der Lo- 
gik und der Semantik kommt dieser Aspekt ganz besonders zum Tragen. 

Im Rahmen einer Plan/Build/Run-Organisation kann nun folgende Zuordnung herge- 
stellt werden: 



Ebene 


Verantwort- 
liche Org. 
inheit 


Funktion 


Fachkenntnisse 


Grad der 

Toolunter- 

stiitzung 


5 


Semantik 


Zentrale 


Plan 


Corporate Identity 
und Untemehmens- 
kommunikation 




4 


Logik 


Fachstelle 
(Anforderer) 


Kenntnisse der 
Geschaftsprozesse 


■ 


3 


Implemen- 
tierung 


Entwickler 
(Umsetzer) 


Build 


Software- 
entwicklung 


■■■■ 


2 


Technologie 


Fachstelle, 

Entwickler, 

Betrieb 


Allg. IT-Security 


■■ 


1 


System 


Betrieb 


Run 


Netzwerk- und 
Systemadmini- 
stration 




0 


Netzwerk & 
Host 



Abbildung 2: Zuordnung der Ebenen 

Die Spalte "Fachkenntnisse" zeigt fiir die einzelnen Bereiche, welche Kenntnisse je- 
weils erforderlich sind. In der letzten Spalte ist dargestellt, in welchem Umfang dabei 
auf Toolunterstiitzung gesetzt werden kann. 
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1.2 Leitfaden fiir bereits bestehende Webanwendungen 



1.2.1 Zur Situation bei alteren Webanwendungen 

Viele altere Webanwendungen sind entweder ohne klare Sicherheitsanforderungen in 
den Produktivbetrieb iibemommen worden oder zu einer Zeit erstellt worden, als das 
allgemeine Verstandnis iiber die Anwendungssicherheit noch sehr gering gewesen ist. 
So ist die Sicherheit einer bestehenden Webanwendung tiaufig dadurch bestimmt, in- 
wieweit die jeweiligen Entwickler Wert auf Sicherheitsaspekte gelegt haben oder das 
erforderliche Know-how vorlag - nicht aber, weil Vorgaben und Abnahmeprozesse 
ein defmiertes Niveau hergestellt haben. Insbesondere in der Anfangszeit der Web- 
nutzung wurde vielfach auf ein professionelles Software-Engineering verzichtet. Ent- 
sprechende "Altlasten" aus Perl- oder anderen Skripten sind haute noch anzutreffen. 



1.2.2 Alle Webanwendungen miissen sicher sein 

In aller Regel gilt: Je alter eine Webanwendung ist, desto weniger wird sie aktuellen 
Sicherheitsanforderungen gerecht. Zunachst ist daher Sorge zu tragen, bestehende 
Webanwendungen auf ein definiertes Sicherheitsniveau zu bringen. Dabei soUte nicht 
von der weit verbreiteten, aber falschen Annahme ausgegangen werden, dass eine un- 
sichere Webanwendung dann zu keinem Schaden fiihrt, wenn sie selbst keine sensi- 
blen Daten bereitstellt oder keine sicherheitsrelevanten Funktionen ausfiihrt. Derm: 
Eine einzige unsichere Webanwendung kann die Sicherheit weiterer Systeme kom- 
promittieren. So z.B. konnten angeschlossene Application- oder Datenbankserver ge- 
fahrdet sein. 



1.2.3 Kosten-Nutzen-Abwagung 

Sicherheitsfunktionen nachtraglich in eine bestehende Anwendung zu integrieren, 
wird sich in den meisten Fallen als schwierig und teuer erweisen. Das gilt auch im 
Falle der Webanwendungen. Ein Programm, das Ein- und Ausgaben nicht iiber zen- 
trale Schnittstellen abwickelt, ist nachtraglich nur miihsam und fehlertrachtig mit 
Funktionen zur Data Validation auszustatten. Gleiches gilt, wenn beispielsweise Ses- 
sion-Merkmale nicht nur zur Authentisierung, sondem gleichzeitig zu anderen Zwe- 
cken genutzt werden, und dadurch beispielsweise die SessionlD nach dem Login 
nicht einfach emeuert werden kann, um auf diese Weise Session Fixation zu verhin- 
dem. 

Bei entdeckten Schwachstellen in bestehenden Anwendungen stellt sich daher regel- 
maBig die Frage, ob sich der Aufwand einer Behebung iiberhaupt lohnt. Bei der Be- 
antwortung dieser Frage darf nicht auBer Acht gelassen werden, dass eine unsichere 
Anwendung unter Umstanden die Sicherheit weiterer Systeme kompromittieren kann. 
Hier ist eine Risikoanalyse unumganglich, bei der zu ermitteln ist, ob der Verzicht 
auf die Behebung der Probleme ein tragbares Risiko darstellt oder aber eine Beseiti- 
gung der Probleme unverzichtbar ist. Erschwerend kann hinzukommen, dass bei be- 
stehenden Anwendungen oftmals die urspriinglichen Entwickler nicht mehr verfiigbar 
sind, und daher fur eine emeute Einarbeitung und Analyse der Webanwendung zu- 
satzliche Kosten entstehen. 
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1.2.4 Einsatz von WebShields 

Eine sinnvoUe MaBnahme zur zusatzlichen Absicherung alterer Webanwendungen 
stellen Web Application Firewalls (auch "Web Shields" genannt) dar. Die Einfiihrung 
eines WebShields sollte jedoch nicht ohne eine Untersuchung der Sicherheitsfunktio- 
nen bestehender Anwendungen geschehen. Wird etwa festgestellt, dass bei einer An- 
wendung durch Eingabe eines Hochkommas SQL-Injection moglich ist, jedoch ande- 
re Eingaben trotz fehlender Data Validation in der Anwendung keine problemati- 
schen Auswirkungen haben, so kann ein WebShield dafur genutzt warden, das Hoch- 
komma herauszufiltem - eine moglicherweise teure Fehlerbehebung in der Anwen- 
dung ware damit nicht erforderlich. Wird jedoch ein WebShield ohne Betrachtung 
der zu schiitzenden Anwendungen als einzige MaBnahme eingesetzt, so kann das zu 
einer falschen Sicherheitseinschatzung fuhren: So z.B. ist das Herausfiltem von Son- 
derzeichen nicht immer ausreichend, um SQL-Injection zu verhindem. 

Das durch ein WebShield erreichbare Schutzniveau sollte trotz des prinzipiell ahnli- 
chen Funktionsprinzips nicht mit dem von Firewalls auf der Netzwerkebene gleichge- 
setzt werden. 



1.2.5 Vorgehen fiir bestehende Webanwendungen 

Folgende Schritte sollten durchgefuhrt werden, um bestehende Webanwendungen auf 
ein defmiertes Sicherheitsniveau zu bringen. Einzelne Punkte davon sind auch im 
nachfolgenden Kapitel weiter ausgefuhrt: 

• Absicherung der Web-Infrastruktur 

- Netzwerk absichem 

- Serverhartung 

- Monitoren von Security Bulletins 

- Patchmanagement 

• Bestandsaufnahme 

- Sicherheitsanalyse der Website als Ganzes 

- Betrachtung der Sicherheit jeder einzelnen Webanwendung 

• Sicherheitsanalyse / Penetrationstest 

- Anwendungen auf das Vorhandensein von Schwachstellen untersuchen 

• Risikoanalyse 

• Festlegung von SchutzmaBnahmen 

- MaBnahmen und Best Practices anwenden 

• Ggf Einsatz eines WebShields 
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• Sicherheit der Webanwendung als Prozess etablieren bzw. in bestehenden Si- 
cherheitsprozess integrieren 

Insbesondere sollte Schritt 3 des folgenden Teilkapitels auch hier beriicksichtigt wer- 
den. 
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1.3 Leitfaden fiir neu zu entwickelnde Webanwendungen 

Bei der Neuimplementierung einer Webanwendung sollten Sicherheitsaspekte im ge- 
samten Software-Entwicklungsprozess, also bereits von Begiim an, beriicksichtigt 
werden. 

Die folgenden Schritte geben Anhaltspunkte fiir ein strukturiertes Vorgehen zur Her- 
stellung eines definierten Sicherheitsniveaus fiir neu zu entwickelnde Webanwendun- 
gen: 



1.3.1 1 - Individuelle Bedrohungsanalyse 

Wahrend groi3e und sicherheitskritische oder auch neuartige Anwendungen einer in- 
dividuellen Bedrohungsanalyse unterzogen werden sollten, konnen fiir eine Vielzahl 
kleinerer und mittlerer Anwendungen in aller Regel allgemeintypische Bedrohungen 
angenommen werden, so dass hier der Aufwand fiir eine detaillierte Bedrohungsana- 
lyse deutlich reduziert werden kann. 

Generell wird bei einer Bedrohungsanalyse untersucht, welchen Bedrohungen die 
Anwendung und ein damit verbundener Gesamtprozess ausgesetzt ist. Mogliche An- 
griffspunkte werden identifiziert und flieBen in die spatere Modellierung der notwen- 
digen technischen und organisatorischen IT-Sicherheitsma6nahmen ein. 



1.3.2 2 - Festschreiben der Verantwortlichkeiten 

Die Verantwortlichkeiten fur einzelne Teilbereiche der Web-Sicherheit sind festzule- 
gen. Als Ausgangspunkt hierfur kann Abbildung 2 (Zuordnung der Ebenen - vgl. Ka- 
pitel 1.1) herangezogen werden. 

Dabei werden die anfordemde Fachstelle, die Entwicklung und der Betrieb als we- 
sentliche Beteiligte gesehen und die Verantwortlichkeiten den Ebenen der Web-Si- 
cherheit zugeordnet. Im Rahmen einer Plan/Build/Run-Organisation ergibt sich die in 
Abbildung 2 dargestellte Zuordnung zu den drei Funktionen. 

Die Fachstelle ist am ehesten in der Lage, die Sicherheit auf der Semantischen Ebene 
und der Ebene der Anwendungslogik zu gewahrleisten. Sic muss davon ausgehen 
konnen, dass die Entwicklungsstelle die Anwendung sicher implementiert hat, und 
dass der Betrieb die Anwendung sicher einsetzt und administriert. 



1.3.3 3 - Umsetzung von SchutzmaBnahmen 

Bei der Umsetzung von SchutzmaBnahmen sind typische und gegebenenfalls spezifi- 
sche Bedrohungen zu beriicksichtigen. Hierbei handelt es sich weitgehend um Be- 
drohungen, denen grundsatzlich jede Webanwendung mehr oder weniger stark ausge- 
setzt ist. Die Kenntnis grundsatzlicher Bedrohungen ist fiir die Auswahl und die Fest- 
legung des Umfangs der anzuwendenden MaBnahmen unverzichtbar. 

Im Folgenden werden die wichtigsten MaBnahmen und Herangehensweisen genannt, 
um eine Webanwendung sicher zu implementieren. Bei der Zuordnung der MaBnah- 
men zu den organisatorisch verantwortlichen Stellen helfen die bei jeder MaBnahme 
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angegebene Ebene und das oben unter 2 gezeigte Schema. 
Systemebene - Ebene 1 

Eine Auswahl hierfur relevanter MaBnahmen ist in M335 bis M400 zusammengefasst. 

Als generelles Prinzip ist der moglichst weitgehende Aufbau einer "Second Line-of- 
Defense" anzuraten: Es ist sicherzustellen, dass nach Kompromittierung einer An- 
wendung die weiteren moglichen Auswirkungen auf den Rest des Systems minimal 
bleiben. Die aufgefuhrten MaBnahmen erhalten hierzu Hinweise. 

Durch das Verfolgen von Security Bulletins, sowie eine zeitnahe Reaktion bei Be- 
kanntwerden von Sicherheitsproblemen ist das System auf aktuellem Sicherheitsstand 
zu hahen (M335). 

Zusatzhch empfehlenswert ist die Beriicksichtigung von Web Security Tools (M420). 
Technologieebene - Ebene 2 

Der Einsatz von SSL fiiir Teilfunktionen oder die gesamte Anwendung ist zu priifen 
(M310). 

Das dem Schutzbedarf angemessene Authentisierungsverfahren ist zu ermitteln. 
Implementierungsebene - Ebene 3 

Data Validation: Die Validierung von Input und Output ist das A und O einer siche- 
ren Webanwendung. Der Datenfluss nicht nur vom Benutzer zur Anwendung und 
umgekehrt, sondem auch zu den verschiedenen Subsystemen, und von dort in die 
Ausgabe, ist zu untersuchen und in ein Konzept zur Data Validation zu integrieren. 
Im Idealfall werden alle lnput-/Output-Daten von einem zentralen Data Vahdation- 
Modul gepriift. Siehe IV1100 bis IV1150 

Session absichiern: Zu den Voraussetzungen fur eine sichere Implementierung des 
Session Management zahlen detaillierte Kenntnisse iiber den Austausch von HTTP- 
Messages, iiber Session-Aufbau und Session- Ablauf, iiber den Austausch und die 
Speicherung von Cookies, sowie Kenntnisse spezifischer Bedrohungen. Grundlegen- 
de MaBnahmen sind in IVI170 und M200 angegeben. Abhangig vom Schutzbedarf ist 
die Session zusatzlich durch die in IVI180 und IVI190 genannten MaBnahmen abzusi- 
chem. Eine Absicherung gegen Session Riding ist bei den gegenwartigen Technolo- 
gien fiir kleinere Anwendungen teuer, bei groBen oder sicherheitskritischen Anwen- 
dungen fallt sie weniger ins Gewicht. !VI220 ist bei entsprechendem Schutzbedarf an- 
zuwenden. 

Weitere grundlegende IVIaRnahmen, die sich oft mit geringem Zusatzaufwand um- 
setzen lassen, sind: 

• Datenbankzugriff mit Prepared Statements oder durch Einsatz von OR-Mappem 
ausfuhren (IVI140) 

• Weiterleitungen (Redirects) niemals unkontrolliert ausfuhren (IVI160) 

• Durch eine entsprechende Architektur des Models (Model- View-Controller) Pri- 
vilege Escalation verhindem (IVI225) 
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Logische Ebene - Ebene 4 

Die Fachstelle hat die Prozesse so zu gestalten, dass sie an keiner Stelle angreifbar 
sind. Dabei ist auf Konsistenz zu achten und der Prozess als Ganzes zu betrachten. 

Insbesondere sind Vorkehrungen gegen Uberflutung und Eniuneration zu treffen. 
Hier muss die Fachstelle der Entwicklungsstelle Vorgaben in Form von Grenzwerten 
xmd Verfahren machen, die sich aus der Auspragung des jeweiligen Geschaftsprozes- 
ses ergeben. (M270, M280) 

Semantische Ebene - Ebene 5 

Falls noch nicht geschehen, so sind auf dieser Ebene untemehmensweite Regelungen 
vmd Konventionen zu schaffen. Dies sollte unter Einbeziehung zentraler Stellen wie 
der Untemehmenskommunikation und des Marketing erfolgen (M260). 
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1.4 Verweise 

Weitere umfassende Quellen zur Sicherheit von Webanwendungen sind frei im Inter- 
net verfugbar, so z.B.: 

• OWASP Guide to Building Secure Web Applications and Web Services. Version 
2.0 [1] und Version 3.0 Working Draft [2] 

• OWASP Web Application Penetration Checklist [3] 

• The OWASP Testing Project [4] 
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MaBnahmen und Best Practices 



In diesem Kapitel werden SchutzmaBnahmen und Best Practices zur Vorbeugung ge- 
gen typische Schwachstellen in Webanwendungen vorgestellt. Die tatsachliche Um- 
setzung einzelner MaBnahmen steht dabei in enger Abhangigkeit von einem konkre- 
ten Projekt. So konnen sich bestimmte, in den meisten Fallen sinnvolle MaBnahmen 
im Einzelfall als unpraktikabel erweisen. Diesbeziiglich ist daher eine geeignete Aus- 
wahl zu treffen. 



2.1 



M 1 00 Data Validation: Filterung 



2.1 MlOO Data Validation: Filterung 



Abstract 



Input und Output einer Webanwendung sind zu validieren und zu filtern. 



Ebene 



Implementierung 



Beschreibung 



Alle Daten, die von auBen in die Anwendung gelangen, sind zu validieren und zu fil- 
tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine 
Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies 
nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt "Output Filte- 
rung" geht auf diese Frage naher ein. 



Eine Input- Validierung hat stattzufinden, bevor die Input-Daten zum Zugriff auf Sub- 
systeme (Datenbanken, Shell, usv^^.) genutzt werden. Dies geschieht im Wesentlichen 
zur Verhinderung von Injection- Angriffen. Eine Output-Validierung hat vor der Aus- 
gabe der Daten in eine Antwortseite stattzufinden. Dies geschieht im Wesentlichen 
zur Verhinderung von Cross-Site Scripting (XSS). Findet die Input- Validierung in 
dem Bewusstsein statt, dass die Daten auch fur die Ausgabe zu validieren sind, kann 
in den Fallen, wo die Herkunfi: der Daten klar ist - also beispielsweise dann, wenn 
die Daten alleine iiber die Form-Variablen in die Anwendung gelangt sind - die Out- 
put-Validierung auch mit der Input- Validierung zusammen erfolgen. 



Filterung ist immer dann angebracht, wenn keine Seiteneffekte zu befiirchten sind 
oder wenn die Art der Datenverwendung gefahrliche Zeichen oder Zeichenketten auf- 
grund ihrer Natur erlauben muss. Ein Forum, in dem iiber JavaScript diskutiert wird, 
kann nicht die Eingabe von <script> verbieten, muss dieses aber als HTML-Tag in- 
validieren. 

Bei der Filterung ist mit groBer Umsicht vorzugehen. AUzu leicht kann eine Variante 
ubersehen werden. 

Problematisch ist z.B. auch der auf den ersten Blick vemiinftig erscheinende Filter 
(hier in Perl RegEx-Syntax geschrieben), um <script>-Tags im Eingabestrom zu 16- 
schen: 

s/<script>//g; 

Dieser kann jedoch mit einer geschachtelten Eingabe umgangen werden. Es ist daher 
rekursiv zu filtern oder gegebenenfalls der Input abzulehnen. 

Input-Filterung 

Die Input- VaUdierung sollte grundsatzlich nach der vollstdndigen Dekodierung der 
vom Browser erhaltenen Daten geschehen. Der Webserver iibemimmt diese Aufgabe 
nicht. Zu den verschiedenen Web-Programmier- und Skriptsprachen existieren je- 



2.1.1 Input- 



versus Output-Validierung 



2.1.2 Filterung 
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weils Bibliotheken, die solche Dekodierfunktionen enthalten. In einem Servlet-Con- 
tainer geschieht dies bei Verwendung der getParameter ( ) -Methode automatisch. 

Im Folgenden wird davon ausgegangen, dass die Eingabedaten bereits in der kanoni- 
schen Form vorliegen. Die Output-Validierung wird konzeptionell von der Input- Va- 
lidierung separiert, auch in den Fallen, wo sie ebenfalls beim Einlesen der Daten 
durchgefiihrt werden kann. So bleibt die Input- Validierung auf die Erkennen derjeni- 
gen Zeichen beschrankt, die beim Zugriff auf Subsysteme potentiell gefahrlich wer- 
den konnten (Blacklist- Ansatz), bzw. die als erlaubte Zeichen gelten (Whitelist-An- 
satz). Die Zeichentabelle ist fiir jedes Subsystem und die jeweilige Art der Verwen- 
dung anzupassen. Grundsatzlich gilt: 

• Whitelisting ist dem Blacklisting vorzuziehen, warm immer moglich. 

• Beim Whitelisting ist zunachst von einer moglichst kleinen Zeichenmenge aus- 
zugehen, die darm individuell erweitert wird. 

• Einfache Filter verwenden; komplexe Filter durch sequentielle Verwendung ein- 
facher Filter nachbilden. 

Die folgende Liste enthalt potentiell gefahrliche Zeichen, nach Subsystem geordnet: 

SQL 

(String) 
% (Wildcard) 

(Wildcard) 
[ (Escape-Zeichen in MS SQL) 
) (Verkniipf ung) 
( (Verkniipf ung) 

@ (Funktion oder Variable, min. in MS SQL) 
; (Kommandokonkatenation) 
+ (Textkonkatenation) 
= (Vergleich) 

< (Vergleich) 

> (Vergleich) 

# (Kommentar ) 
(Kommentar ) 

/* (Kommentar) 

\0 

\r 

\n 

\t 

\h 

Systemaufrufe 

Je nach Betriebssystem sind fiir Systemaufrufe folgende Metazeichen als potentiell 
problematisch einzustufen: 

' (Parameterubergabe) 

" (Parameterubergabe) 

(Kommandoauf ruf ) 

I (Kommandoauf ruf , Pipelining) 

> (Redirection, Ausgabe) 

< (Redirection, Eingabe) 

* (Wildcard) 
? (Wildcard) 

; (Kommandokonkatenation) 

$ (Variablennamen) 
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(Path Traversal) 

I 

& (Kommandokonkatenation) 

( 

) 

\0 
\r 
\n 

LDAP 

Werden die Daten als Anfrage fiir ein LDAP System benutzt, dairn sind folgende Zei- 
chen als potentiell problematisch einzustufen: 

( 
) 



LDAP Metazeichen: 



Sonstige 

alle nicht druckbaren Zeichen von Hex-0 bis Hex- 19, insbesondere 

das Null-Byte \o, URL-enkodiert: %oo 

Carriage Return (CR), \r, URL-enkodiert: %0a 

Linefeed (LF) \n, URL-enkodiert: %0d 

Tabulator \t, URL-enkodiert: %0 9 

Output-Filterung 

Die Output-Filterung in Richtung Web-Browser muss sicherstellen, dass der Zeichen- 
strom keine Zeichen oder Zeichenketten enthalt, die der Browser als Code (HTML, 
JavaScript, ActiveX, usw.) interpretieren wiirde. Diese Anforderung ist am einfachs- 
ten dadurch zu erfuUen, dass die Zeichen, die als Code interpretiert werden konnten 
oder in den "Codemodus" umschalten, als solche invalidiert werden. Dieses Ziel kann 
durch Umwandlung in die Darstellung als sog. Named Character Reference erreicht 
werden. Auch wenn die Entscheidung, welche Zeichen umzuwandeln sind, von den 
individuellen Verhaltnissen abhangt, ist die Ersetzung dieser 5 Zeichen in der Regel 
ausreichend: 

& ==> Samp; 
< ==> < 
> ==> > 
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" ==> " 
' => &#39; 

Kommt also beispielsweise die Zeichenkette <script> iiber die Eingabe in den Aus- 

gabedatenstrom, so wird sie zu &it; script sgt; invalidiert und im Klartext ange- 
zeigt anstatt als Beginn eines Skriptes interpretiert. 

Weitere Details zur Output-Filterung, insbesondere HTML-Encoding und URL-En- 
coding, finden sich in M150.9 "Ausgabedaten filtem". 

Zu beachten ist insbesondere auch, dass immer dann, wenn Parameter in den Respon- 
se-Header geschrieben werden, diese auf das Vorhandensein von CRLF-Zeichen zu 
filtem sind, um Header-Manipulation zu verhindem. 

Anmerkung 

Vielfach wird das Klammem von Benutzereingaben mittels des <pre>-Tags als L6- 
sung empfohlen. Dieser Ansatz verhindert aber nicht, dass die geklammerten HTML- 
Tags interpretiert werden und soUte daher nicht zum Einsatz kommen. 

Zu beachten ist welter, dass das &-Zeichen zuerst ersetzt wird, da es bei alien folgen- 
den Ersetzungen wieder als Meta-Zeichen gebraucht wird. Gleiches gilt fur das ; 
wenn dieses ersetzt wird. 
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2.2 MHO Data Validation: Whitelisting statt Blacklisting 

Abstract Wann immer moglich, ist Filterung nach dem Whitelist-Verfahren dem Black- 

list-Verfahren vorzuziehen. 

Ebene Implementierung 

Beschreibung 

Eine grundsatzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips: 
Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster defmiert, die 
aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim 
Whitelisting ist es umgekehrt: was nicht ausdriicklich erlaubt ist, ist verboten. Black- 
listing ist dann problematisch, wenn als "nicht kritisch" erkannte Zeichen im Verlaufe 
der weiteren Verarbeitung zu einem ungewollten Systemverhalten fiihren. 

Werden problematische Muster vergessen oder nicht erkannt oder kommen neue pro- 
blematische Muster hinzu, so werden sic beim Whitelist-Ansatz hingegen automa- 
tisch geblockt. Beim Blacklist-Ansatz werden sie solange durchgelassen, bis die Re- 
geln angepasst werden. Ein Beispiel fur letzteren Fall ist der Fortschritt in den Inter- 
net-Standards. Die Einfiihrung von HTML 4.0 hat gegeniiber der Vorgangerversion 
einige neue Elemente gebracht, die als problematisch angesehen werden koimen. 
Eine mit Blacklisting geschiitzte Anwendung ist hiervon nach der Einfiihrung von 
HTML 4.0 solange betroffen, bis die Blacklist angepasst worden ist. 

Blacklist- und/oder Whitelist-Verfahren werden haufig nicht nur mit festen Schliis- 
selwortem benutzt, sondem auch als Regulare Ausdriicke realisiert. 

Generell ist das Whitelist-Verfahren dem Blacklist- Verfahren vorzuziehen. 

Beispiel 

Der folgende Test in Perl soli fur einen Parameterwert alle Buchstaben oder Zahlen 
erlauben: 

$wert = s/ ['^a-zA-ZO-9] //g; 
Anmerkung 

1: das Negationszeichen in der Zeichenklasse erweckt zunachst den Eindruck, dass 
es sich hier um eine Blacklist handelt. Tatsachlich ist der Befehl so zu lesen: "losche 
alle Zeichen auBer Buchstaben und Zahlen". 

2: in dem Beispiel werden explizit alle Zeichen (z.B. a bis z) aufgezahlt, und keine 
vordefinierten Zeichenklassen (z.B. \w oder \d) benutzt. Das ist wichtig, da solche 
Zeichenklassen nicht der Kontrolle des Programmierers imterliegen. Sie konnten sich 
zum Beispiel andem, wenn eine Anwendung von einer Plattform auf eine andere por- 
tiert wird oder sich die Version der Programmiersprache (hier Perl) andert. 

Ein Blacklist-Filter ware z.B.: 

$wert = s /( script I obj ect) /$ l_tag/ig; 

Diese Blacklist wird die HTML-Tags object und script ersetzen. Unberiihrt davon 
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Bemerkung 



bleibt z.B. das EMBED-Tag, welches ahnlich problematisch sein kann wie das script- 
Tag. 



Bei der Implementierung gilt ebenso, wie schon in M100 erwahnt, dass man besser 
mehrere einfache Filter nacheinander verwendet, statt einen einzigen, sehr komple- 
xen Filter zu konstruieren. 
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2.3 M120 Data Validation: Behandlung von manipuliertem Input 

Abstract Manipulierter Input ist generell abzulehnen. Weitere Hinweise fiber die Ursache 

des Fehlers sind nicht zu geben. 

Ebene Implementierung, Logik 

Beschreibung 

Bei der Behandlung von ungiiltigem Input kann zvv^ischen zwei Fallen unterschieden 
werden: 1) Fehleingaben des Benutzers, und 2) bewusste Manipulation. Im ersten 
Fall ist in benutzerfreundlicher Weise zu reagieren - unter Wahrung des Minimali- 
tatsprinzips, vgl. M250, M320. Der Benutzer ist auf den Fehler hinzuweisen und bei 
der Korrektur entsprechend zu fuhren. 

Im zweiten Fall sollte die Reaktion in geeigneter Weise den Manipulationsversuch 

abwehren. Dann ist zu entscheiden, ob eine Filterung erfolgt oder ob die Weiterverar- 
beitung abgelehnt wird. Eine erfolgreiche Filterung konnte eine Weiterverarbeitung 
implizieren. 

Bin sicheres Kriterium fiir den Abbruch der Verarbeitung mit einer Fehlermeldung ist 
immer dann gegeben, w^enn die Eingabedaten mit bestimmungsgemaBer Brow^serbe- 
dienung nicht eintreten konnen, wie z.B.: 

• Zusatzliche oder fehlende Form-Variablen 

• Das Session-Cookie enthalt Zeichen, die von der Anwendung nicht vergeben 
werden oder es entspricht nicht der definierten Lange. 

• In HIDDEN-, SELECT- odcr CHECKBOX- Variablcn transportierte Werte wurden ver- 
andert oder entsprechen nicht dem Muster, welches die Anwendung gesetzt hat. 

• Die Quelle der Variablen (z.B. GET, POST, Cookie) stimmt nicht mit der Vorga- 
be der Anwendung iiberein. 

Zu den moghchen Reaktionen auf derartige Fehler konnen je nach Situation zahlen: 

• Die weitere Verarbeitung ist zu stoppen. Es ist zu erwagen, statt einer Fehlermel- 
dimg eine Reaktion in dieser Weise vorzunehmen: Dem Benutzer - dem in die- 
sem Fall ein Angriff unterstellt wird - wird der korrekte Umgang mit der Einga- 
be vorgetauscht, um seinen Angriffsversuch zu unterlaufen und weiteres Suchen 
nach Schwachstellen zu erschweren. So wiirde die Antwort auf das manipulierte 
Absenden eines Kontaktformulars beispielsweise genauso wie im korrekten Fall 
lauten: "Vielen Dank fiir Ihre Anfrage, die wir umgehend bearbeiten." (siehe 
M250 "Minimalitatsprinzip"). 

• Es ist zur Homepage oder Sitemap oder der (neutralen) Seite, die auch bei Zu- 
griffen auf nicht vorhandene Seiten angezeigt wird, zuriickzukehren. 

• Es ist eine explizite Wamung auszugeben, dass ein Angriffsversuch festgestellt 
worden ist und dass alle Zugriffsversuche protokolliert werden bzw. anderweiti- 
ge MaBnahmen ergriffen werden. 
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• Zusatzlich bei bestehender Session: Der Benutzer ist auszuloggen und die Sessi- 
on zu invalidieren (siehe M170.6 "Session beenden", M170.7 "Sessions behan- 
deln in PHP"). 

Nicht korrekt sind diese haufig anzutreffenden Reaktionen: 

• ungefilterte Ausgabe der Fehlermeldung (liefert u. U. fur einen Angriff verwert- 
bare Infomationen) 

• Server Error 500 (daraus lasst sich schlieUen, dass die Anw^endung nicht alia Fal- 
le korrekt abfangt) 

• "Die Anwendung ist momentan w^egen Wartungsarbeiten nicht verfugbar" (gibt 

dem Angreifer u. U. einen Anreiz, die Anwendung weiter zu untersuchen, da er 
vermutet, dass er die Anwendung tatsachlich kurzzeitig lahm gelegt hat) 

Ganzlich abzuraten ist in solchen Fallen von Versuchen, fehlerhafte Eingaben zu kor- 
rigieren. Derartige Versuche weisen das unnotige Risiko auf, doch nicht fehlerfrei zu 
sein und einen Angriff dadurch uberhaupt erst zu ermoghchen. 
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2.4 M130 Data Validation: Selektive Filterung von HTML-Tags 

Abstract Sind HTML-Tags in besonderen Fallen als Eingabe erlaubt, so ist moglichst ein 

eigenes Markup zu verwenden. 

Ebene Implementierung 

Beschreibung 

Ausgesprochen schwierig ist die Output-Filterung, wenn begrenztes Markup seitens 
des Benutzers erlaubt sein soil. Dies kommt beispielsweise vor bei webbasierten Sei- 
tengeneratoren, wie einige Webspace-Provider sie anbieten oder bei Versteigerungs- 
und Kleinanzeigen-Plattformen, wo die Angebote seitens des Benutzers mit Bildem 
oder Hervorhebungen ausgestattet werden konnen. Dann muss der Filter in der Lage 
sein, erlaubte HTML-Tags von problematischen Tags zu unterscheiden. Dieser An- 
satz ist jedoch mit dem hohen Risiko behaftet, doch etwas zu iibersehen. Vorzuziehen 
ist daher der Ansatz, fur das Markup des Benutzers eine eigene Markup-Sprache zu 
definieren. Diese wird dann von der Anwendung in die zugehorigen HTML-Tags 
iibersetzt. Herkommliche Tags bzw. problematische Zeichen werden nach wie vor 
ausgefiltert. 

Ein mogliches Verfahren, wenn nur einfaches Markup zugelassen werden soil, ist die 

Verwendung von { und } statt < und >. Fett wiirde dann als {F}Dies ist Fett{/F} 
geschrieben und ein Bild wiirde auf diese Weise platziert: 

{img src=/images/img . gif width=l height=l img} 

Selbstverstandlich darf die Umwandlung in HTML dann nicht aus geschweiften 

Klammem einfach spitze Klammem machen, sondem muss jedes Tag als Ganzes an- 
sehen: { img nach <img, img} nach >, src=Datei nach src="Datei" (wobei Datei zu 
filtem ist), usw. 
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2.5 M140 Data Validation: SQL-Injection verhindern 

Abstract Statt Embedded bzw. Dynamischem SQL sind Prepared Statements oder andere 

sichere Techniken fiir den Datenbankzugriff zu verwenden. 

Ebene Implementierung 

Beschreibung 

2.5.1 Prepared Statements 

Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter 
SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer- 
den. Software-Entwickler miissen sich im Rahmen des Designs einer Funktion oder 

hat bzw. was die Menge aller moglichen Abfragestrukturen ist, die in Abhangigkeit 
vom Input zur Ausfiihrung gelangen konnen. Diese Abfragen sind in Form von Pre- 
pared Statements auszuformulieren. Dabei kann mit den Mitteln der Prepared State- 
ments (also in der Regal entsprechenden If- Abfragen und dem Zusammensetzen von 
Abfragen) alien Bedingungen, die durch unterschiedlichen Input zu priifen sind, 
Rechnung getragen werden. Es besteht also in aller Regel keinerlei Notwendigkeit, in 
die Formulienmg des Statements zusatzlich eine Dynamik hineinzubringen, die nur 
mit dem Mittel der Dynamic Statements erreichbar ware. 

2.5.2 Stored Procedures 

Stored Procedures haben im Hinblick auf ihre Sicherheit gegeniiber SQL-Injection 
ahnhche Eigenschaften wie Prepared Statements. Auch hier ist zu beachten, dass bei 
Ubergabe von unvalidierten Parametern an eine Stored Procedure moglicher proble- 
matischer Input nicht automatisch abgefangen wird. In [5] wird beschrieben, wie sich 
entsprechende Probleme beheben lassen. 



2.5.3 SQL-Injection und Java 

Der Zugriff auf SQL-Datenbanken erfolgt bei Java durch die JDBC-Schnittstelle 
(Java Database Connectivity). Von den jeweiligen Datenbankherstellem werden Im- 
plementationen dieses Interfaces, sog. JDBC-Treiber, zur Verfiigung gestellt. 

Parameter, die vom Benutzer ubergeben werden, miissen validiert werden. Das kann 
auf folgende Weisen geschehen: 

Eigene Filter-Funktion 

In jeder Programmiersprache ist es moglich, durch Schreiben einer Escape-Funktion 
die SQL-Query-Routine abzusichem. Eine solche Routine konnte folgendermaBen 
aussehen: 

public static String escapeSQL (String stringToBeEscaped) 
{ 

StringBuffer escapedBuf f er = new StringBuf f er ( ) ; 
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for (int i = 0; i < stringToBeEscaped. length () ; i++) 
{ 

char c = StringToBeEscaped. charAt (i) ; 

switch (c) 

{ 

case ' \ ' ' : 

escapedBuff er . append ( " ' ' ") ; 

break; 
case '\0' : 

escapedBuffer.append("\\0") ; 

break; 

// ... hier weiteres Datenbank-spezif isches Quoting 

default : 

escapedBuff er . append (c) ; 

} 

} 

return escapedBuff er . toString ( ) ; 

} 

Bin Nachteil dieser MaBnahme ist, dass alle problematischen Zeichen in Bezug auf 
die gerade benutzte Datenbank bekamit sein mussen. 

Benutzung von java . sql . PreparedStatement 

Die vorteilhaftere Moglichkeit im Falle von JDBC ist die Benutzung eines 
j ava . sql . PreparedStatement. Hierbei werden zunachst Platzhalter in einem SQL- 
Query' gesctirieben und anschliel3end diese Parameter mit setstring ( ) gesetzt. Der 
datenbankspezifische JDBC-Treiber iibemimmt dabei das richtige Kodieren des Para- 
meters. Dies ist immer fiir die jeweilige Datenbank passend und zuverlassig gelost 
(unterschiedliche Datenbanken haben unterscliiedliches Quoting!). 

Beispiel: 

PreparedStatement preparedStatement = 

j dbcConnection . prepareStatement ("select * from user where id=?"); 
preparedStatement . setstring (1, param) ; 

ResultSet resultSet = preparedStatement . executeQuery () ; 
Benutzung von Objekt-relationalen Mapping-Tools 

Heutzutage ist die Benutzung eines Objekt-relationalen Mapping-Tools (OR-Mapper) 
in der Java-Entwicklung sehr verbreitet. Diese Tools erlauben einen direkten Zugriff 
auf eine relationale Datenbank. Es ist in der Regel davon auszugehen, dass diese 
Tools j ava . sql . PreparedStatement benutzen. Dass dies tatsachlich so ist, muss bei 
der Benutzung verifiziert werden. 

Oftmals lassen diese Tools bei komplexeren Abfragen eine Hintertiir offen, indem ein 
Teil der Abfrage als SQL iibergeben werden kann. In diesem Fall miissen die Para- 
meter, die iibergeben werden, zuvor richtig kodiert werden. 

Vermeidung von "execute ()" 

Die JDBC API lasst bei den Klassen statement und PreparedStatement die folgen- 



' Diese SQL-Query-Routine darf keine Befehle enthalten, die dazu fuhren, dass sie doch wieder 
interpretiert wird, z.B. bei Verwendung von execSQLQ 
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den Methodenauirufe zu: 

executeQuery ( "sql . . .") 

execute ( "sql . . . " ) 

executeUpdate ( " sql . . . " ) 

Bei Benutzung der Klasse statement sollte der Aufruf execute ( ) vermieden wer- 
den, da es bei einigen Datenbanken moglich ist, ein SQL-Kommando zu beenden und 
ein zweites SQL-Kommando anzuhangen. Somit kann ein an sich harmloses Select- 
Kommando beendet werden und ein Update-Kommando angehangt werden. 

Daher sollte bei einem Select-Kommando immer die Methode executeQuery ( ) imd 
bei einem Update-Kommando die Methode executeUpdate ( ) benutzt werden. 



2.5.4 SQL und MS SQL 

MS SQL bietet selbst eine Moglichkeit, jeden Parameter als Stringliteral fiir ein SQL- 
Query zu betrachten: Parameter collection. Dazu sind SQL-Queries z.B. wie folgt 
zu konstruieren: 

SqlDataAdapter myCommand = new SqlDataAdapter ( 

"SELECT name FROM users WHERE name=@uid", myConnection) ; 

SqlParameter parm = myCommand . SelectCommand. Parameters .Add ( "@uid", 
SqlDbType . VarChar, 11); 

parm. Value = Request . QueryString ( "par ") ; 
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2.6 M150 Data Validation: Diverse MaBnahmen 



Abstract Weitere MaBnahmen und Tipps zur Data Validation. 

Ebene Implementierung 

Beschreibung 

Zusammenfassung wichtiger Funktionen 



M150.1 Eingabeabfrage in ASP 

Das ASP.Net Framework stellt viele Funktionen bereit, um die Parameter, die der 
Browser gesendet hat, an die Anwendung weiterzugeben. Es konnen Funktionen ver- 
wendet werden, die gezielt nach einem Parameter an einer bestimmten Stella suchen 
(z.B. Request . Form ( ) ) oder eine Funktion (z.B. Request { ) ), die den Parameter an 
iiblichen Stellen sucht (siehe auch M230 "Post erzwingen") 

Grundsatzlich ist immer die Request-Funktion zu verwenden, welche nur den Para- 
meter liefert, den man auch erwartet. Also z.B. Request . Querystring { "par" ) fur 
einen GET-Request oder Request . Form ( "par" ) fur einen POST-Request oder 

Request . Cookies ( "par" ) oder Request . ClientCertif icates ( "par" ) oder 
Request . ServerVariables ( "par" ) statt Request ( "par" ) . 



M150.2 Serverseitig validieren 

Alle Eingabedaten sind von der Anwendung auf dem Server zu validieren. Priifungen 
auf dem Client (Browser) z.B. mittels JavaScript konnen allenfalls aus Griinden der 
Benutzerfreundlichkeit erfolgen, aber niemals um Annahmen iiber die Beschaffenheit 
der Eingabedaten sicherzustellen. Priifungen im Browser konnten vom Benutzer ab- 
geschaltet und beliebig manipuliert werden. 



M150.3 Namen von Form-Variablen filtern 

Genauso wie der Wert einer Form-Variablen kann auch ihr Name beliebig manipu- 
liert werden. Daher sind auch die Namen von Form-Variablen der Filterung zu unter- 
ziehen. 

Da alle Form-Variablen in der Anwendung bekannt sind, ist hier ein einfaches String- 
Mapping sehr effektiv. 

Beispiel in Perl: 

use CGI; 

my $q = new CGI; 
my $name = ' ' ; 

$name = 'meinName' if (defined $q->param("name") ) ; 

M150.4 Lange/GroCe der Eingabedaten begrenzen 

Alle Eingabedaten sind auf ihre GroBe zu uberpriifen, bevor sie verwendet (insbeson- 
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dere kopiert) werden. Die genaue Realisierung dieser Priifung ist von der jeweiligen 
Programmiersprache abhangig. Beispiele^: 

Beispiel in Perl: 

exit (22) if (length ($parameter) > 42); 
Beispiel in PHP: 
if (strlen ($parameter) > 42) { return; }; 

Achtung: die PHP-Funktionen geben im String enthaltene Null-Bytes direkt als sol- 
che welter. Null-Bytes mussen zuvor entfemt werden. In Perl sind keine String- 
Funktionen bekannt, die dieses Problem haben. 

M150.5 Datentyp der Eingabedaten 

Welchen Datentyp die Eingabedaten haben, bestimmt zunachst die Konfiguration des 
Webservers. Allgemein muss die Applikation annehmen, dass die Daten binar sind. 
D.h. dass URL-kodierte Zeichen wie der Null-Character (%oo) oder das Carriage Re- 
turn-Linefeed (%0d%0a) bereits in die jeweiligen binaren Zeichen umgewandelt wor- 
den sind. Die Applikation muss den Wertebereich, und damit den Datentyp, selbst 
iiberpriifen. Je nach Programmiersprache steht dazu eine Fiille von Funktionen zur 
Verfiigung. Bei der Auswahl der Funktionen ist darauf zu achten, dass die Daten 
nicht verandert werden (manche Funktionen filtem derart, dass nur dem Wertebe- 
reich entsprechende Daten zuriickgeliefert werden). Falsche Daten sind abzulehnen, 
nicht zu korrigieren. 

M150.6 Filterung von Datentyp und DatengroBe mittels RegEx 

Mit Regularen Ausdriicken (RegEx) katm man Datentyp und DatengroBe zusammen 
priifen. Hier z.B. mit Perl: 

exit(22) if ($parameter !~ [a-zA-Z] { 1, 42 } $) ; 

exit(22) if ($parameter !~ [a-zA-ZO- 9 ] { 1 , 42 } $ ) ; 

exit (22) if ($parameter !~ [a-zA-ZO-9 ] { 2 , 9 } @ [a-zA-Z0-9\ . - ] { 5 , 99$ ) ; 

M150.7 Filterung in ASP.Net 

Ab der Version 1 . 1 bietet das ASP.Net-Framework eigene Funktionen fiir die Daten- 
priifung an. Interessant sind hierbei Rangevaiidator und 

RegularExpressionValidator. 

ASP Range VaHdator: 

<asp : RangeValidator 
ControlToValidate="textbox" 
MinimumValue=" 1 " 
MaximumValue=" 100" 
Type=" Integer" 



^ Der Einfachheit halber ist in den genannten Beispielen ein exit aufgerufen. Dies ist bei der Realisierung 
selbstverstandlich durch eine geeignete Fehlerbehandlung zu ersetzen. 
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EnableClientScript=" false" 
Text="Gultige Werte von 1 bis 100!" 
runat="server" /> 

Fiir Type stehen zur Verfugung: 

Currency 

Date 

Double 

Integer 

String 

ASP RegularExpressionValidator: 

<asp : RegularExpressionValidator 
ControlToValidate="textbox" 
ValidationExpression="\d{ 5 } " 

EnableClientScript=" false" 

ErrorMessage="The zip code must be 5 numeric digits!" 
runat="server" />; 

Bemerkung: Die Controls setzen und liefem nur eine Fehlermeldung. Sie unterbre- 
chen nicht den Programmfluss - das muss der Programmierer weiterhin selbst reali- 
sieren, indem die Riickgabewerte iiberpruft werden. 

M150.8 Datenlange begrenzen in Perl 

Mit dem Perl-Modul CGI.pm kann man die GroBe der POST-Daten zusatzlich be- 
grenzen. Man beachte aber, dass der Webserver bereits alle Daten vom Browser ent- 
gegengenommen hat: 

use CGI; 

$CGI: :POST_MAX = 1024 * 1; # entsprechend anpassen 

$CGI :: DISABLE UPLOADS = 1 ; 



M150.9 Ausgabedaten filtern 

Fur das HTML-Encoding und URL-Encoding bieten die einzelnen Programmierspra- 
chen unterschiedliche Hilfsmittel und Funktionen an. Generell gilt, dass alle "nicht- 
druckbaren" Zeichen sowie die meisten Sonderzeichen durch HTML-Entities ersetzt 
vv^erden miissen. 

HTML-Encoding 

Beispiele in ASP: 

Response. Write ("Wert: " + Server . HTMLEncode (Request . Form ( "par "))) ; 

Beispiel in Java: 

In Java kann man die Priif-Funktion vaiidHTML und die Konvertier-Funktion 
saveHTML verwenden. 

public class Validator // requires JDK 1.4 or higher 
{ 

private static final String 

DEFAULT CHARS TO BE ENCODED = "<&>\"'"; 
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public static String encodeHTML (String stringToBeEncoded) 
{ 

return 

encodeHTML (DEFAULT_CHARS_TO_BE_ENCODED, StringToBeEncoded) ; 

} 

public static String encodeHTML (String charsToBeEncoded, 

String strToBeEncoded) 

{ 

if (StrToBeEncoded == null | | charsToBeEncoded == null) { 
return (strToBeEncoded) ; 

} 

Pattern pattern = Pattern . compile ("[ " + charsToBeEncoded + "]"); 
Matcher matcher = pattern .matcher (strToBeEncoded) ; 
StringBuffer encodedBuf f er = new StringBuf f er ( ) ; 
while (matcher . find 0 ) { 

String match = matcher . group () ; 

matcher . appendReplacement (encodedBuf fer, "&#" + 

match. getBytes 0 [0] + ";"); 

} 

matcher . appendTail (encodedBuf fer ) ; 
return encodedBuf fer . toString () ; 



public static void main (String [ ] args) 
{ 

String par = "ham & <b>eggs</b>" ; 

System. out. print ("encodedHTML: " + Validator . encodeHTML (par )) ; 
// --> encodedHTML: ham & &#60 ; b&#62 ; eggs&#60 ; /b&#62 ; 

} 

} 

Anmerkung: Beide Funktionen arbeiten mit selbstdefinierten Expressions, far deren 
Korrektheit der Programmierer verantwortlich ist. Falls solche Funktionen in einer 
Bibliothek zur Verfugung gestellt werden, ist von beiden Funktionen abzuraten. 



Beispiel in Perl: 

In Perl gibt es viele Moglichkeiten, die Daten fur die Ausgabe entsprechend zu kodie- 
ren. Die wichtigsten davon sind in den nachfolgenden Beispielen aufgelistet. Es wur- 
de explizit nicht die Zeichenklasse \w (Perl RegEx) verwendet, um sicherzustellen, 
dass alle Zeichen konvertiert werden. 



$encode_encl =~ s/ ( [ ''a-zA-ZO-9 
$encode_hexl =~ s/ ( [ ^a-zA-ZO-9 

$encode_hex2 =~ s / ( [ •^a-zA-ZO-9 
$encode_intl =~ s/ ( [ "a-zA-ZO-g 
$encode_int2 =~ s/ ( [ '^a-zA-ZO-g^ 

Man kann auch folgende Funktion fur sicheres HTML-Encoding verwenden: 

sub saveHTML ($) { 
my $str = $_; 

$str =~ s/ ( [^a-zA-Z0-9_.-] ) /sprintf ( ' &#x%04x; ' , ord($l) ) /ge; 
return ($str) ; 

} 

print "Parameter: ", saveHTML ($par) , • 



.-])/'%' .unpack( 'H*' , $1) /ge; 
.-])/' &#xOO ' .unpack ( ' H* ' , $1) . ' ; ' /ge; 
. - ] ) /sprintf ( ' &#x%04x; ' , ord ($1) ) /ge; 
.-])/'&#' . unpack ('C*',$l) . '; '/ge; 
.-])/'&#' .ord($l) . '; '/ge; 



Das Perl-Modul cgi .pm bietet ebenfalls eine eigene Funktion fur sicheres HTML-En- 
coding. 



my $q = new CGI; 

$q->autoEscape (1) ; # default 
print "Parameter: ", $q->escapeHTML ($par) ; 
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Anmerkung: Die obigen Perl-Beispiele erwecken zunachst den Eindruck, dass ein 
Blacklist- Verfahren verwendet wird - wo von in MaBnahme M110 explizit abgeraten 
vv^ird. Dam ist aber nicht so, denn die Priifimg lautet in Worten z.B.: "alle Zeichen au- 
Ber a-z oder A-Z oder 0-9 oder _ oder . oder - ". Es wuide lediglich die logische Um- 
kehrung verwendet. 

URLs in HTML 

URLs (Links) in der HTML-Seite miissen besonders kodiert sein. Diese Teile der 
Ausgabe sind also abweichend von der oben (HTML im Text) beschriebenen Metho- 
de umwandeln. 

Beispiel in Java: 

java. net. URLEncoder. encode (aURL, "ISO-8859-1") ; 

Beispiel in ASP: 

var BaseURL = "http : //www.mysite . com/search2 . asp?searchagain=" ; 
Response . Write ( "<a href=\"" + BaseUrl 

+ Server . URLEncode (Request . QueryString ( "par" ) ) 

+ "\">click-me</a>" ); 

Beispiel in Perl: 

Perl selbst bietet dafiir keine Funktion, sie kann aber einfach wie folgt definiert wer- 
den 

sub saveURL ($) { 
my $str = $_; 

$str =~ s/ ( ['^a-zA-Z0-9_.-] ) /sprintf ( '%%%02x; ' ,ord($l) ) /ge; 
return ($str) ; 

} 

Anmerkung: die obigen Beispiele benutzen teilweise die Input-Parameter direkt, 
ohne Filterung. Das widerspricht der MaBnahme M100, in welcher auf genau diese 
Probleme hingewiesen wird. In den Beispielen wurde der Ubersichtlichkeit halber be- 
wusst auf eine vorherige Input-Filterung verzichtet. 



M150.10 LDAP-Injection vermeiden (Java) 

Parameter in Suchfiltem, die die Giiltigkeit und die Absicht des Filters verletzen, 
miissen "escaped" werden. Von einer eigenen Escape-Funktion wird hier abgeraten, 
da das JNDI dafur eine spezielle Such-Methode bereitstellt, die automatisch alle spe- 
ziellen Zeichen escaped. Hierbei werden der Suchmethode ein Filter-Template mit 
Parametem ({0}, {!}, {2}, usw.) und die Parameter als Object- Array iibergeben. 

Hier ist ein Beispiel, das diese Methode demonstriert: 

string f ilterTemplate = " (userPassword= { 0 } ) " ; 

SearchControls searchControls = null; // default SearchControls 
NamingEnumeration answer = j ndiDirContext . search 

(f ilterTemplate, new Object [] {pw} , searchControls); 
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M150.il 



Escape-Funktionen 



Als Anhaltspunkt seien hier Escape-Funktionen verschiedener Programmiersprachen 
aufgefiihrt: 



Request . Form ( ) 
Request . QueryString ( ) 
Request . Cookies ( ) 
RangeValidator ( ) 
RegularExpressionValidator ( ) 
Server . HTMLEncode ( ) 
Server . URLEncode ( ) 



class j ava . sql . PreparedStatement 
j ava . net . URLEncoder . encode ( ) 



addslashes ( ) 

quote_meta ( ) 

mysql real escape_string ( ) 
strip_tags ( ) 
htmlentities () 
utf8 decode 0 



ASP 



Java 



Perl 



CGI : : autoEscape ( ) 
CGI : lescapeHTML 0 



PHP 
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2.7 M160 URL-Weiterleitungen (Redirects) kontrollieren 



Abstract Weiterleitungen sind durch geeignete MaBnahmen vor Missbrauch zu schiitzen 

Ebene Semantik, Logik, Implementierung 

Beschreibung 

Wir geben hierfiir MaBnahmen an, die je nach Umstanden und Anforderungen anzu- 
wenden sind: 



M160.1 Nur bekannte Links weiterleiten 

Sind die Links, auf die weitergeleitet wird, auf bestimmte beschrankt, so ist die Wei- 
terleitung auch nur fiir diese zu erlauben. Alle anderen Parameter sind abzulehnen. 
Das ist am besten dadurch zu erreichen, dass nicht die Ziel-Seite selbst als Parameter 
ubergeben wird, sondem ein Index in eine Tabelle, die serverseitig gehalten wird, 
und in der alia in Frage kommenden URLs enthalten sind. Ein Redirect- Aufrufwiirde 
daher statt: 

http : / /www . shop_abc . tld/ redir ?url= http : / /www .hersteller xyz . tld/ 

so lauten: 

http : / /www . shop_abc . tld/ redir ?url=5 

wobei das Ziel http : //www . hersteiier_xyz . tld/ in der Tabelle unter der Nummer 
5 abgelegt ist. 



M160.2 Manuelle Weiterleitung fiber Zwischenseite 

Statt die Umlenkung direkt und fur den Benutzer transparent durchzufuhren, ist sic 
indirekt iiber eine Seite zu fuhren, die dem Benutzer angezeigt wird. Damit kann die- 
ser den Link vor dem aktiven Klick priifen und selbst entscheiden, ob er diesem ver- 
traut. Ein Aufixif z.B. von: 

https : / /b2b . abc-ag . tld/ q= https : / / www . anqreif er . tld/b2b-abc-aq . html 

wiirde, statt direkt zum Ziel weiterzuleiten, eine Seite wie diese an den Browser zu- 
riickliefem: 



Sie werden auf folgende externe Webseite weitergeleitet. 

https : / /www . angreif er . tld/b2b-abc-ag . html 

Aus Sicherheitsgrijnden fuhren wir die Weiterleitung nicht automa- 
tisch durch. Bitte kontrollieren Sie den Link und setzen Sie die 
Weiterleitung gegebenenf alls durch Klick fort. 



Der in diese Seite eingetragene Link hat eine Data Validation zu durchlaufen, damit 
er nicht zu einer Cross-Site-Scripting-Schwachstelle fuhrt. 
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M160.3 Referrer-Test durchfiihren 

Ahnlich wie in M220, kann auch hier der Test des Referrers einen gewissen Schutz 
bieten. Die Umleitung ist nur dann auszufuhren, wenn der Referrer die URL der Seite 
enthalt, auf der sich der Weiterleitungslink befindet. Eine XSS-Schwachstelle kann 
aber auch hier diesen Schutz wieder zunichte machen. 



M160.4 Lokale Weiterleitung einschranken 

Erfolgt die Weiterleitung auf eine Seite auf der eigenen Website, so ist vor der Aus- 
fuhrung zu priifen, dass als Parameter keine URL iibergeben worden ist, die auf eine 
exteme Seite flihrt. Am einfachsten werden lokale Weiterleitungen ausschlieBlich mit 
relativen Pfaden durchgefuhrt und der Host-Teil statisch hinzugefugt. 

Statt also die Weiterleitung so zu programmieren, dass ein voUqualifizierter Link 

https : //b2b . abc-ag. tld/q=http : // b2b . abc-aq. tld/neu/seite5 .html 
iibergeben werden muss, soUte der Parameter von dieser Form sein: 

https : //b2b . abc-ag. tld/q= /neu/ seiteS . html 
und der Teil http : //b2b . abc-ag . tid statisch hinzugefugt werden. 



M160.5 Header-Manipulation verhindern 

Weiterleitungen sind eine typische Quelle fur Header-Manipulation-Schwachstellen. 
Es ist daher besonders darauf zu achten, dass dies nicht auftritt. 
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2.8 M170 Session Management 



Abstract Das Session Management ist eine der problematischsten Stellen fur die Sicher- 

heit von Webanwendungen. Fiir den Schutz der SessionID sollten daher entspre- 
chend wirksame MaOnahmen zur Anwendung kommen. 

Ebene Logik, Implementierung 

Beschreibung 

Der Schutz der Session vor einem Eindringen lasst sich durch Beriicksichtigung der 
im Folgenden genannten MaBnahmen deutlich verbessem. Die Beachtung dieser 
MaBnahmen ist daher der durchzufuhrende Mindestschutz. 

Wenn im Folgenden von Cookies die Rede ist, dann ist damit immer ihre Eigenschaft 
als Trager der SessionID gemeint. 



M170.1 SessionID nach Authentisierung erneuern 

Nach erfolgreicher Authentisierung (Login) ist eine schon bestehende SessionID 
durch eine neue zu ersetzen. 

In einer Java Servlet-Umgebung ist eine Anderung der SessionID in direkter Weise 
nicht moglich. Stattdessen kann folgende Variante gewahit warden: Sessiondaten 
speichem - alte Session invalidieren - neue Session erstellen - gespeicherte Daten in 
neue Session kopieren. Im Detail: 

1. Nach erfolgreichem Login sind die Daten aus der bestehenden Session zu spei- 
chem 

string savedUrl = (String) 

session . getAttribute ( "SESSION_REDIRECT_URL" ) ; 

2. Dann ist die bestehende Session zu invalidieren 

session . invalidate ( ) ; 

3. SchlieBlich ist eine neue Session zu erstellen - damit w^ird gleichzeitig eine neue 
SessionID vergeben 

session = request . getSession () ; 

4. Und die gespeicherten Daten in die neue Session zu kopieren. 

if ( savedUrl != null) 

session. setAttribute ("SESSION_REDIRECT_URL", savedUrl) ; 

5. Jetzt ist der Loginvorgang beendet und der Benutzer setzt die Bearbeitung mit ei- 
ner neuen SessionID fort. 



M170.2 Cookies einschranken 

Cookies sind, wenn sie Trager von sensitiven Informationen sind (insbesondere der 
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SessionID), auf einen minimalen "Aktionsradius" zu beschranken, um die Gefahr zu 
minimieren, dass sie von nicht vertrauenswiirdiger Seite aufgefangen werden. 

Eine gute Cookie-Definition sieht so aus: 

Set-Cookie: SESSIONID=iojew984389hui78g; path=/appl/portal; secure; 
HttpOnly 

Der Pfad ist auf die Anwendung einzuschranken, secure- und HttpOniy-Flag (siehe 
unten) sind zu setzen. 

Damit diese Pfad-Einschriinkung moglich ist, sind alle an einer Anwendung beteilig- 
ten Ressourcen unterhalb des Einstiegspfades zu platzieren. 

Domain-Cookies sollten grundsatzlich vermieden werden. (z.B. 
domain= .meinedomain . tid, d.h. Domain-Cookies werden an jeden Host in der Do- 
main geschickt). Architekturen, die Domain-Cookies benotigen, sind sehr genau auf 
die Auswirkungen auf die Sicherheit zu untersuchen. 



Wann immer eine Anwendung SSL-Verschliisselung benotigt, ist das Cookie mit 
dem secure-Flag zu defmieren. Damit wird sichergestellt, dass der Browser das Coo- 
kie niemals iiber eine unverschliisselte Verbindung iibertragt. Beispiel: 

Set-Cookie: SESSI0NID=lk8usdj iui090iwef ; path=/myApp; secure 



Im Cookie ist das HttpOniy-Flag zu setzen. Es verhindert beim Internet Explorer ab 
Version 6 SPl, dass das Cookie von JavaScript etc. gelesen werden kann. Eine XSS- 
Liicke kann daher nicht mehr zum Auslesen des Cookies genutzt werden. 

Die Verwendung ist jedoch nicht unproblematisch: Die wichtigsten aktuellen Brow- 
ser neben dem Internet Explorer akzeptieren zwar Cookies mit dem HttpOniy-Flag, 
vmterstiitzen aber dessen Funktionalitat nicht, d.h. hier verhalt es sich wie ein ganz 
normales Cookie, katm also nach wie vor von JavaScript etc. gelesen werden. Bei 
manchen alteren Browsem fiihrt die Angabe dieses Flags zudem zu einem Syntaxfeh- 
ler und damit zur Ablehnung des Cookies. Damit das Session Management auch bei 
Verwendung des HttpOniy-Flags in jedem Fall funktioniert, ist daher zusatzHch die 
Browser- Version zu priifen und das HttpOniy-Flag nur dann zu setzen, wenn der In- 
ternet Explorer ab Version 6 SPl oder hoher angetroffen wird. Da nun aber wiederum 
auf die Erkennung des user-Agent-Headers nicht immer Verlass ist, kann die Ver- 
wendung des HttpOniy-Flags in manchen Fallen zu Problemen mit dem Session Ma- 
nagement fuhren. 

Syntax: Das HttpOniy-Flag wird einfach als zusatzliches Attribut in den set- 
cookie-Header geschrieben. Beispiel: 

Set-Cookie: SESSI0NID=lk8usdj iui090iwef ; path=/myApp; HttpOnly 

Von den meisten Frameworks wird es noch nicht unterstiitzt. Ein Patch zur Unterstiit- 
zung des HttpOniy-Flags in PHP4 findet sich in [6]. 



M170.3 



secure-Flag setzen 
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Siehe [7] Protecting Data with HTTP-only Cookies. 

Bemerkung: Das HttpOniy-Flag verhindert nicht den schreibenden Zugriff auf ein 
so deflniertes Cookie (auch nicht beim Internet Explorer!). Es ist daher wirkungslos 
gegeniiber Session Fixation- Angriffen. 

M170.5 RFC 2965-/ Version 1-Cookies verwenden 

Wir verweisen an dieser Stelle lediglich auf das Vorhandensein einer restriktiveren 
Form von Cookies, den "RFC 2965"- oder auch "Version l"-genannten Cookies. Die- 
ses zu den herkommlichen Cookies kompatible Format - es fuhrt den set-cookie2 
Header ein - schrankt die Angreifbarkeit auf Cookies ein gutes Stiick weit ein. Da sie 
jedoch gegenwartig in den Browsem entweder gar nicht oder aber uneinheitlich im- 
plementiert sind, gehen wir hier nicht naher darauf ein. 

Siehe [8] RFC 2965 

M170.6 Session beenden 

Jede Session ist aktiv zu beenden. Dazu kann die Applikation dem Benutzer die In- 
itiative, z.B. in Form eines Logout Buttons, iiberlassen. Die Applikation muss aber 
auch eine fest eingestellte maximale Lebensdauer einer Session uberpriifen. Sie darf 
sich auf keinen Fail auf ein bestimmtes Verhalten des Benutzers (z.B. Verwendung 
des Logout Button) verlassen, da dies aus vielfaltigen Grunden ausbleiben kann. Fol- 
gende Kriterien sind zu beachten und an geeigneter Stelle im Programm umzusetzen: 

• maximale Lebensdauer einer Session (Timeout) 

• maximale Dauer, in der keine Aktion in einer Session stattfinden (Idletime) 

• Logout durch Benutzer 

• Logout durch Fehlersituationen 

Die Sessiondaten miissen im Programm voUstandig geloscht werden, um zu verhin- 
dem, dass die Session wieder- bzw. weiter verwendet werden kann. In Java: 

session . invalidate ( ) ; 

Im Browser des Benutzers sollte ein moglicherweise vorhandenes SessionlD-Cookie 
geloscht werden. Das kann dadurch erreicht werden, dass das Cookie emeut gesetzt 
wird, allerdings mit einem in der Vergangenheit liegenden Expires-Attribut, am bes- 
ten mit dem hier gezeigten Wert (Response-Header): 

Set-Cookie: SESSIONID=123455789; expires=Thu, Ol-Jan-70 00:00:01 GMT 
Fiir PHP siehe M170.7 und M390. 



M170.7 Handhabung von Sessions in PHP 

Session erzeugen 

Die API von PHP suggeriert eine sehr einfache Handhabung der Session-Objekte 
und SessionlD. Leider ist diese in der Literatur verbreitete Vorgehensweise nicht im- 
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mer ausreichend sicher. PHP unterscheidet nicht selbst, ob eine neue Session erfor- 
derlicti ist oder eine bekannte Session benutzt wird. Um wirklich neue Session-Ob- 
jekte und SessionlDs zu erzeugen, ist wie folgt vorzugehen: 

session_name ( ' eigene-SessionID ' ) ; 
session_id ( ' ' ) ; 
session_start ( ) ; 

session_id ( ' eigener zufalliger Wert'); 

PHP verwaltet die Sessiondaten standardmaBig in Dateien. Damit stellt sich die Frage 
des Zugriffsschutzes auf diese Dateien. Eine alternative Methode besteht darin, fur 
die Speicherung der Sessiondaten eine Datenbank zu benutzen. Leider bringt PHP 
(bis einschl. 4.x) keine Zugriffsfunktionen mit, so dass sie selbst programmiert wer- 
den miissen. In der Konfiguration wird dann der PHP-interne Handler abgeschaltet 
und auf den benutzerspezifischen gesetzt. In einem entsprechenden PHP-Skript miis- 
sen dann mit session_set_save_handier ( ) die eigenen Funktionen registriert wer- 
den. Um dies zu ermoglichen, wird die php.ini wie folgt konfiguriert: 

[sessions] 

session . save_handler = user 

SessionID erneuern 

In PHP kann mit session_regenerate_id ( ) eine neue SessionID fur eine existie- 
rende Session vergeben werden. Dieser Schritt ist auszufuhren nach Authentisierung 
einer bereits zuvor vergebenen Session. 

Session beenden 

In PHP kann ein Session-Objekt mit den Funktionen session unset ( ) und 
session_destroY ( ) zerstort werden, die Daten existieren im zugehorigen Skript 
aber bis zu dessen Ende waiter. Die Daten mussen explizit geloscht werden. 



Weitere Hinweise zum Umgang mit Sessions und der Konfiguration von PHP fmden 
sich in M390, Abschnitt (5) "Sessions absichem" 



Abhangig davon, ob URL-Rewriting eingesetzt wird oder ob Cookies als Transport- 
mittel fur die SessionID verwendet werden, sind unterschiedliche SicherheitsmaBnah- 
men zu ergreifen. Nur derjenige Transportmechanismus darf Verwendung fmden, fur 
den die zugehorigen SicherheitsmaBnahmen auch umgesetzt sind. Nutzt eine Anwen- 
dung den vom Applicationserver oder der Servlet-Engine bereitgestellten Automatis- 
mus, je nach Browser-Fahigkeiten eigenstandig zwischen beiden Verfahren umzu- 
schalten, so muss die Anwendung auch fur beide Verfahren die Sicherheitsvorausset- 
zungen erfullen. Ist das nicht der Fall, darf der Automatismus nicht eingeschaltet 
sein. Im Sicherheitsprozess ist dafiir Sorge zu tragen, dass eine entsprechende Ab- 
stimmung zwischen Anwendung und Konfiguration des Applicationservers hinsicht- 
lich der SessionlD-Transportart erfolgt. 



Erfordert die Anwendung URL-Rewriting, so sollte ein Benutzer auf die Gefahren 
des Ausspahens hingewiesen und dazu aufgefordert werden, sich beim Verlassen des 
PCs aus der Webanwendung auszuloggen oder den Rechner zu sperren. Durch Ver- 



M170.8 



SessionlDs und Transportmedium 



M170.9 



URL-Rewriting: Benutzer informieren 



Bundesamt fur Sicherheit in der Informationstechnik 



43 



2.8 M170 Session Management 



wendung sehr langer SessionlDs, die ein Abschreiben erschweren oder die Verwen- 
dung langer URLs mit der SessionlD am Ende (so dass sie aus dem sichtbaren Be- 
reich am Bildschirm herausgeschoben ist) kann zudem etwas gegen das Uber-die- 
Schulter-schauen getan warden. 

Insbesondere ist ein Benutzer darauf hinzuweisen, niemals eine gespeicherte Seite 
oder einen kopierten Ausschnitt aus einer solchen Seite zu versenden. 

M170.10 URL-Rewriting: Externe Links diirfen keine SessionlD enthalten 

Es ist sicherzustellen, dass beim URL-Rewriting nicht versehentlich auch externe 
Links mit der SessionlD versehen werden. Das nachste Beispiel weist daher keine 
SessionlD im dritten Link auf: 

<html><body> 

Guten Tag Herr Meier, <br> 

Sie sind eingeloggt im E-Business Portal der XYZ AG.<P> 
<a href="portal?doFirma; iew98z94t30dsfn89wfe "> 

Ihre Firmendaten</a><br> 
<a href="portal?doTrans; iew98z94t30dsfn89wfe "> 

Ihre Transaktionen</a><br> 
<a href =" https : / / portal .partner. tld/ uid=meier "> 

Ihr Account bei unserem Partner</a><br> 

</body></html> 

M170.il URL-Rewriting: Referrer-Leck verhindern 

Der Referrer, der beim Einsatz des URL-Rewritings auch die SessionlD enthalt, darf 
nicht zu fremden Hosts gelangen. Dies ist dadurch sicherzustellen, dass Links auf ex- 
terne Seiten niemals direkt gesetzt werden, sondem immer uber einen Redirect ge- 
fiihrt werden. 

Statt also den Link zur extemen Site www. externesite . tid, der sich auf dieser Seite 
befindet 

https : //www.meineanwendung. tld/getUSerinf o; JSESSIONID=koiasd756dbhvf 

SO zu setzen: 

<a href =" https : / /www . externesite . tld/schaumalhier ">Klick</ a> 

ist dieser so zu formulieren: 

<a href ="https : / /www .meineanwendung . tld/ redirect ?url= 

https : / /www . externesite . tld/schaumalhier ">Klick</ a> 

Nach dem Redirect ist der Referrer https : / /www.meineanwendung. tid/ 
getuserinf o; jsEssiONiD=koiasd756dbhvf nun crsctzt durch den Redirect-Link, 
der die SessionlD nicht mehr enthalt. (vgl. auch M160) 

Besonders dann, wenn der auf einer Seite innerhalb einer Session angezeigte Inhalt 

von externer Quelle stammt, ist Vorsicht geboten (Beispiel: Der Benutzer einer Shop- 
ping- Anwendung hat diesen Eintrag eingegeben, beispielsweise in einem Kommen- 
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tar-Feld, den der ausfiihrende Bearbeiter sich nun ansieht). Hier kann das Referrer- 
Leck nicht so einfach verhindert werden wie in dem gerade beschriebenen Fall, bei 
dem der Inhalt unter der voUen KontroUe des Betreibers steht. Klickt der Shop-Bear- 
beiter auf den enthaltenen Link, ist seine SessionlD iiber den Referrer schon zum An- 
greifer iibertragen. Folgende MaBnahmen sind in diesen Fallen zu ergreifen: 

• Benutzereingaben sind nicht nur auf potentiell problematische HTML-Tags zu 
filtem. Auch href-, und sonstige Tags, die zum Ausliefem des Referrers fiihren, 
sind zu filtem. 

• Die Inhalte sind in einem iNPUT-Feld anzuzeigen (wobei selbstverstandlich XSS 
verhindert werden muss). 

Kann auf das Anzeigen solcher Links nicht verzichtet werden (Webmail-Anbieter 
stehen beispielsweise vor diesem Problem), so ist dies auf einer Seite durchzufuhren, 
in der die SessionlD in der URL nicht enthalten ist. Dazu ist die Anzeige der Seite 
wie oben gezeigt iiber einen Redirect zu fiihren. Die Session-Information ist auf einer 
solchen Seite dann allerdings nicht mehr vorhanden, d.h. diese Seite kann keine 
Links zum Fortsetzen der Session enthalten. 
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2.9 M180 Session Management: Bindung der IP-Adresse an die 
Session 



Abstract Eine Session kann durch Einbeziehung der IP-Adresse des Clients als kenn- 

zeichnendes Merkmal zusatzlich geschiitzt werden, sofern die daraus resultie- 
renden Probleme in Kauf genommen werden konnen. 

Ebene Implementierung 

Beschreibung 

Die IP-Adresse des Client-Computers ist ein weiteres Kriterium, das zur Verhinde- 
rung von Session Hijacking herangezogen werden kann: Die Anwendung hinterlegt 
bei der Instanziierung der Session die IP-Adresse des Clients und iiberpriift bei jedem 
Zugriff, ob diese mit der hinterlegten IP-Adresse weiterhin ubereinstimmt. Ist das 
nicht der Fall, wird die Session invalidiert. 

Nachteilig an diesem Losungsansatz sind deutliche Beschrankungen in Bezug auf 
mogliche Einsatzumgebungen: Die Bindung der IP-Adresse an die Session funktio- 
niert nicht oder nur eingeschrankt fur all jene Benutzer, die sich hinter einem Proxy 
befinden. Das trifft z.B. auf groBere Organisationen oder auch auf Kunden eines In- 
temet-Access-Providers zu, der eine Proxy- Architektur einsetzt. In einer solchen Um- 
gebung kann es vorkommen, dass im Verlaufe einer Applikations-Session der ausge- 
hende Proxy oder Router wechselt, und damit bei der Webanwendung eine andere IP- 
Adresse registriert wird. 

Als weitere Hindemisse sind software- und netzwerktechnische Gegebenheiten zu 
neimen, die dazu fuhren konnen, dass bei der Webanwendung die IP-Adresse des zu- 
greifenden Benutzers gar nicht ankommt, sondem nur diejenige eines vorgeschalteten 
Reverse-Proxy oder einer anderen Komponente im eigenen Netz. 

Eingesetzt werden kann der vorgeschlagene Losungsansatz jedoch in jenen Anwen- 
dungssituationen, in denen die oben genannten Nachteile nicht eintreten oder toleriert 
werden konnen. So z.B. sind die beschriebenen Hindemisse in der Regel in Intranet- 
Bereichen nicht vorhanden, so dass hier die Bindung der Session an die IP-Adresse 
bei Anwendungen mit erhohtem Schutzbedarf als eine zusatzliche SicherheitsmaB- 
nahme erfolgen kann. 
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2.10 M190 Session Management: Sicherheit erhohen durch 
zusatzliche Parameter 

Abstract Die Session ist durch Verwendung weiterer identifizierender Merkmale des Cli- 

ents zusatzlich zu schiitzen. 

Ebene Implementierung 

Beschreibung 

Problematisch fiir das Session-Management ist die Ubertragung der SessionID iiber 
einen einzelnen Trager. Der Gedanke liegt daher nahe, die SessionID auf verschiede- 
ne Trager zu verteilen, und so den gleichzeitigen Zugriff auf mehrere Trager zu er- 
schweren oder gar zu verhindem - oder aber weitere Merkmale an die Identifikation 
der Session zu binden. 

User-Agent-Header 

Im User-Agent-Header schickt der Browser seine Typenbezeichnung mit. Die An- 
wendung konnte diese bei der Instanziierung der Session darin hinterlegen und bei je- 
dem Zugriff priifen, ob der user-Agent-Header mit dem hinterlegten weiterhin uber- 
einstimmt. 1st das nicht der Fall, wird die Session invalidiert. 

Dieses Vorgehen bringt keine oder nur unwesentliche Verbesserungen gegeniiber: 

• Sniffing, Ausspahen, Referrer-Sniffing, Scripting 
Eine Verbesserung wird erreicht gegeniiber: 

• Speichem, Copy/Paste 

• Session Fixation: Bin Angriff kann dadurch nicht verhindert werden. Hierzu 
miisste zunachst die Browserversion des Benutzers ermittelt werden. 

Bewertung: Auch wenn diese MaBnahme keinen wirklichen Schutz darstellt, ist sie 
doch zu empfehlen. Sie ist recht leicht durchfuhrbar und hat auBer dem zusatzlichen 
Implementierungsaufwand keine weiteren Nachteile. 

Accept- und Accept-Language-Header 

Diese Header weisen nur eine sehr geringe Variationsbreite auf Es gelten ansonsten 
dieselben Einschrankungen wie beim user-Agent-Header. Sie sind als zusatzliches 
Identifikationsmerkmal daher auch nur bedingt geeignet. 

Referer-Header 

Der Referer-Header enthalt die URL der zuletzt besuchten Seite (genauer eigent- 
lich: der Seite, in der sich der geklickte Link befrndet). Mit seiner Hilfe sind ausge- 
kliigelte und aufwandige Verfahren fiir ein sehr sicheres Session Management imple- 
mentierbar. Siehe dazu z.B. [9]. 

Im Sinne einer einfachen Losung kann der Referer-Header ahnlich wie der user- 
Agent-Header verwendet werden. Die Anwendung wiirde dann bei jedem Zugriff zu- 
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satzlich priifen, ob der Referrer auch mit einem fur alle Zugriffe festen Teil des Pfa- 
des beginnt, also beispielsweise: https : //www. test . tld/meineAnwendung/. 

Es ist zu beriicksichtigen, dass einige Browser erlauben, die Ubermittlung des Refer- 
rers zu deaktivieren. Auch Content-Filter (sowohl im Browser als auch auf Proxys) 
konnen entsprechend eingestellt warden. 

Bemerkung 

Ein Problem aller beschriebenen Ansatze stellt die Tatsache dar, dass diese von den 
vorhandenen APIs - namentlich der Servlet-API - nicht unterstiitzt werden und von 
der Anwendung selbst implementiert werden miissten. 
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2.11 M195 Session Management: Kombination verschiedener 
Trager mit Dialogtracking 

Abstract Hier werden die Verfahren zur Implementierung erhohter Sicherheit beim Ses- 

sion Management genannt. 

Ebene Implementierung 

Beschreibung 

Der Weg zu einem Session Management mit besseren Sicherheitseigenschaften fiihrt 
iiber eine Art Kombination der Cookie-Technik mit der Technik des URL-Rewri- 
tings. 

Variante 1 

Zusatzlich zur SessionID (die im Cookie transportiert wird) wird mit der Erzeugung 
der Session eine weitere, von der SessionID verschiedene, nicht erratbare ID erzeugt, 
die wir SessionCode nennen. Der SessionCode wird in jeder URL als zusatzlicher Pa- 
rameter eingefugt. Beim Aufinf der URL (d.h. Klick auf den Link oder Button) priift 
die Anwendung die Ubereinstimmung des iibergebenen mit dem in der Session hin- 
terlegten SessionCode. Stimmen sie nicht iiberein, so wird die Ausfuhrung gestoppt 
und die Session invalidiert. 

Dieses Verfahren ist sehr ahnlich dem in M220 beschriebenen Verfahren zur Verhin- 
derung von Session Riding. Weitere Details sowie ein Implementierungsbeispiel in 
Java konnen dieser MaBnahme entnommen werden. 

Das Verfahren vereint die jeweiligen Vorteile von Cookies und URL-Rewriting. 
Wird das Verfahren wie in M220 beschrieben implementiert, so stellt es gleichzeitig 
eine wirksame MaBnahme gegen Session Riding dar. 

Variante 2 

Die sicherste Form des Session Managements erreicht man durch ein Dialogtracking. 
Dabei ist der oben eingefiihrte SessionCode nicht statisch, sondem wird bei jedem 
Zugriff neu vergeben. Wir bezeichnen jenen SessionCode als Token. 

Die Anwendung baut in jeden Dialogschritt (d.h. jeden Link in einer Seite) das diesen 
Dialogschritt eindeutig kennzeichnende Token ein. Erhalt sie einen Request, priift sie, 
ob das Token fur diesen Aufruf giiltig ist und streicht es aus der Liste der giiltigen 
Token. Ein erneuter Aufruf dieses Links (Replay durch den Angreifer) ist damit nicht 
mehr moglich. Auch ist es nicht moglich, eine Aktion ohne Token aufzurufen. Die 
Kenntnis der SessionID und eines auf dem Ubertragungsweg ausgespahten Tokens ist 
damit nicht mehr ausreichend, um in die Session einzudringen. Man muss gleichzei- 
tig auch das Token von mindestens einem "unverbrauchten" (d.h. noch nicht aufgeru- 
fenen) Link besitzen. 
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2.12 M200 Session Management: Logout erzwingen 

Abstract Jede Anwendung, die eine Login-Funktion hat, soUte auch eine Logout-Funktion 

besitzen. Das Logout hat das korrekte Invalidieren der Session sicherzustellen. 

Ebene Logik 

Beschreibung 

Das Logout muss die SessionID zuverlassig invalidieren. Bei zahlreichen Weban- 
wendungen ist zu beobachten, dass eine Logout-Funktion zwar vorhanden ist und der 
Benutzer nach Ausfiihrung auch die Bestatigung erhalt, nun abgemeldet zu sein, dass 
die Session aber nicht invalidiert wird. Zu erkennen ist das meist daran, dass die Be- 
tatigung des Zuriick-Buttons des Browsers bis zu einer Seite innerhalb der Anwen- 
dung ein Weiterarbeiten darin nach wie vor ermoglicht. Mit einer gestohlenen Sessio- 
nID konnte in einem solchen Fall weitergearbeitet werden (Stichwort "Internet- 
Cafe"). 

Der Benutzer ist darin zu trainieren, das Logout auch wirklich auszufuhren. Dazu ist 

• der Logout-Button deutlich sichtbar darzustellen. 

• der Benutzer nach dem Login darauf hinzuweisen, sich nach Beendigung auch 
wieder auszuloggen. 

• der Benutzer darauf hinzuweisen, sich beim nachsten Mai korrekt auszuloggen, 
falls dies beim letzten Mai nicht geschehen ist. 

SchlieBt der Benutzer das Browser-Fenster in der Annahme, sich dadurch auch auto- 
matisch auszuloggen (was ja nicht der Falls ist), so sollte die Anwendung den Benut- 
zer beim nachsten Login dariiber informieren, dass ein automatisches Ausloggen er- 
folgte, und in Zukunft ein explizites Ausloggen stattfinden sollte. 
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2.13 M210 Anforderungen an eine SessionlD 



Abstract Wird die Erzeugung der SessionlD nicht einer ausgereiften API iiberlassen, son- 

dern selbst implementiert, sind bestimmte Anforderungen zu beachten. 

Ebene Logik, Implementierung 

Beschreibung 

Nicht immer kann oder soil die Erzeugung und Verwaltung einer SessionlD von einer 
ausgereiften API (Servlet-Engine, Applicationserver, ...) ausgefuhrt werden. Fiir die- 
se Falle sollten folgende Anforderungen beriicksichtigt werden: 

• Keine Verkniipfung mit extern bekannten oder erratbaren Daten. Dazu gehoren: 
IP-Adresse des Clients, Uhrzeit, Prozess-ID, Attribute des Benutzers wie Ge- 
burtsdatum oder externa Schliissel wie die E-Mail- Adresse. 

• Hohe Zufalligkeit (Randomness): Das Erzeugungsmuster darf nicht aus einer 
Menge von Proben ableitbar sein. 

• Die SessionlD muss eine ausreichende Lange haben, um gegeniiber Brute-Force- 
Angriffen - dem Durchprobieren aller Moglichkeiten - zu bestehen. 

• Sie sollte ausschlieBlich iiber sichere Kanale iibertragen werden, wenn der 
Schutzbedarf der Anwendung dies erfordert. Siehe M170.8 und M310. 

• Die SessionlD einer Anwendung, deren Schutzbedarf SSL erfordert, darf nie- 
mals versehentlich iiber eine unverschliisselte Verbindung mit iibertragen wer- 
den. Siehe M170.3 (secure-Flag setzen). 

• Die Session selbst muss das kiirzestmogliche Ablaufdatum haben, das fiir den je- 
weiligen Anwendungszweck gerade noch angemessen ist. 
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2.14 M220 Session Riding 



Abstract 



Session Riding ist durch Einfiihrung eines SessionCodes oder durch eine andere 
SchutzmaBnahme zu verhindern. 



Ebene 



Implementierung 



Beschreibung 



Die im Folgenden angefuhrten Mafinahmen sind geeignet, um Session Riding zu ver- 
Schwachstellen, so konnen diese jedoch eine SchutzmaBnahme wieder aushebeln. 
Einfugen eines SessionCodes 

Eine Anwendung ist immer dann anfallig fiir Session Riding-Angriffe, wenn der Re- 
quest mitsamt all seinen GET- und POST-Parametem erratbar ist. Daraus folgt be- 
reits, dass Anwendungen, welche die SessionlD mit der Technik des URL-Rewritings 
transportieren, nicht verwundbar sind, denn einer der Parameter ist gerade die nicht 
erratbare SessionlD. 

Die einfachste SchutzmaBnahme fur Anwendungen, die die SessionlD per Cookie 
transportieren oder eine schwache Authentisierungsmethode verwenden, beruht nun 
darauf, einen geheimen Schliissel {SessionCode - siehe M195) als zusatzlichen Para- 
meter einzufuhren. Der SessionCode ist bei Eintritt in die Session zu vergeben und 
wenigstens in alle Zugriffe einzubauen, die zu Zustandsanderungen fiihren oder Sei- 
teneffekte auslosen konnen. Er ist entweder in die URL zu schreiben oder als Hidden- 
Field zu iibertragen. Der SessionCode darf nicht als Cookie gesetzt werden, da er 
dann genauso wie die SessionlD automatisch mitgeschickt wiirde. Die Anwendung 
iiberpriift bei jedem solchen Aufruf, ob der SessionCode mit dem in der Session hin- 
terlegten iibereinstimmt und lehnt im Fehlerfall die Ausfuhrung ab. 

Es sei darauf hingewiesen, dass die Verhinderung von Session Riding gegenwartig 
von den vorhandenen APIs zum Session Management nicht unterstiitzt wird. Der 
Aufwand, die beschriebene MaBnahme fiir bestehende Anwendungen umzusetzen, 
kaim daher betrachtlich sein. Welter unten geben wir ein Codebeispiel in Java 

Diese MaBnahme ist dann nicht erforderlich, wenn alle zustandsandemden Requests 
vor der Ausfuhrung vom Benutzer mit der Eingabe eines nicht erratbaren Wertes be- 
statigt werden. Dieser Fall kann beispielsweise bei einer Online-Anwendung vorlie- 
gen, die fiir derartige Abfi-agen die Eingabe eines Einmal-Passwortes verlangt. 

Der SessionCode kann auch die SessionlD selbst sein. Dann ist jedoch die Gefahr ge- 
geben, dass durch Ausnutzung einer moglicherweise vorhandenen XSS-Schwachstel- 
le das Cookie, und damit auch der SessionCode, gestohlen werden kann. Wenn es 
keinen hoheren Aufwand bedeutet, fiir den SessionCode eine von der SessionlD ver- 
schiedene ID zu verwenden, ist dies vorzuziehen. Damit ist dann auch gleich eine 
deutlich hohere Sicherheit vor Session Hijacking gegeben. 

Umsetzung in Java 

Nach dem erfolgreichen Login des Benutzers wird der (hinreichend lange und hinrei- 
chend zufallige) SessionCode uniqueLoginSessionCode erzeugt und in der Session 
abgelegt. Das geschieht gleich nach den Vorkehrungen zur Verhinderung von Sessi- 
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on Fixation (M170.1): 

public void setAuthenticatedUser (UserIF userObject) 
{ 

protectSessionFixation () ; 

getSession ( ) . setAttribute (ControllerConstants . SESSION_USER, 

userObject) ; 

getSession ( ) . setAttribute (LOGIN_SESSIONCODE, 

ControllerUtils . getNextUniqueLoginSessionCode ( ) ) ; 

} 

Der SessionCode ist, wenn nicht grundsatzlich, so doch zumindest in alien Fallen, wo 
zustandsandemde Operationen ausgefiihrt werden, als GET-Parameter in den Link 
oder Hidden-Field in die Fom zu schreiben. In der ControUer-Schicht der Anwen- 
dung ist dann der erhaltene Wert mit dem in der Session gespeicherten zu verglei- 
chen. Stimmen sie nicht iiberein oder fehlt der Parameter, so ist die Verarbeitung ab- 
zubrechen und die Session sicherheitshalber zu invalidieren. 

Abfrage eines SessionCodes 

In speziellen Fallen kann eine weitere MaBnahme sinnvoll sein, die jedoch aus Sicht 
des Benutzers mit wiederum erhohtem Aufwand verbunden ist: Nach dem Absenden 
eines kritischen Requests durch einen Benutzer wird zunachst eine Seite mit einer zu- 
falligen Zeichenfolge (eine andere Form eines SessionCodes) angezeigt. Erst wenn 
diese Zeichenfolge durch Eintippen in ein entsprechendes Eingabefeld, und nachfol- 
gendes Ubersenden an die Webanwendung bestatigt wird, erfolgt die Ausfuhrung des 
kritischen Requests. Auch der Einsatz von Captchas kommt hierfur in Frage 
(M270.1). 

Referrer-Test 

Eine wichtige Regel lautet, sich nicht alleine auf den Ref erer-Header zu verlassen. 
In diesem Fall konnen wir eine Ausnahme machen und ihn als zusatzliches Merkmal, 
welches dem Benutzer nicht von auBen untergeschoben werden kann, verwenden 
(von den unten genannten Einschrankungen einmal abgesehen). Diesem Ansatz liegt 
die Annahme zugrunde, dass ein Request nur dann legitim ist, wenn er durch einen 
Klick auf einer zur Anwendung gehorenden Seite ausgelost worden ist. Und immer 
darm ist auch der Ref erer-Header mit der URL dieser Seite belegt. Die Anwendung 
muss also prufen, ob der iibergebene Referrer in der Liste der in Frage kommenden 
URLs vorhanden ist und kann im Positiv-Fall davon ausgehen, dass es sich um die le- 
gitime Verwendung handelt. Wie der nachste Absatz zeigt, ist es wichtig, dabei die 
gesamte URL zu matchen und nicht nur den Host-Anteil. 

Einschrankung 1 

Der so erreichte Schutz kann durch eine XSS-Schwachstelle auf derselben Site - ggf. 
auch auBerhalb der Anwendung selbst - wieder zunichte gemacht werden. Zwar lasst 
sich der Referrer per JavaScript nicht direkt manipulieren, iiber den Umweg des 
Cross-Site Scripting ist es dann aber doch moglich. 

Einschrankung 2 

Der Referrer ist nicht immer verfugbar, da ihn manche Content-Filter auf Client-Seite 
herausfiltem. 
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Bemerkung 

Wird eines der beiden in M 195 beschriebenen Verfahren zur Verhinderung von Sessi- 
on Hijacking implementiert, so wird damit auch gleichzeitig Session Riding wirksam 
verhindert. 
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2.15 M225 Privilege Escalation verhindern 



Abstract Verhinderung von Privilege Escalation in modernen Webanwendungen. 

Ebene Implementierung 

Beschreibung 

Privilege Escalation bezeichnet die unautorisierte Erhohung der Privilegien, die ei- 
nem angemeldeten Benutzer zugeordnet sind. 

Beispielhaft habe eine Anwendung zur Bestellabwicklung fur jede neue Bestellung 
eine eindeutige ID vergeben. Diese IDs warden in der Reihenfolge der Bestellaufgabe 
und iiber alle Benutzer hinweg sequentiell erzeugt. Ein Benutzer kann sich die eige- 
nen Bestellungen iiber eine Web-Schnittstelle anzeigen lassen. Ausgegeben wird eine 
Liste von Bestellungen, die durch eine Folge nun nicht mehr zusammenhangender 
IDs identifiziert werden. Nur auf diese Bestellungen soil der Benutzer zugreifen diir- 
fen. Beim anschlieBenden weiteren Zugriff auf eine konkrete Bestellung wird die ID 
als Parameter mit ubergeben. Privilege Escalation kann nun dann vorliegen, wenn 
die Anwendung beim Zugriff auf einen Datensatz nicht mehr priift, ob der Benutzer 
rechtmaBiger Eigentiimer dieses Datensatzes ist, sondem einfach die als Parameter 
iibermittelte ID zum Zugriff auf die Datenbank heranzieht. 

Zur Verhinderung von Privilege Escalation muss beim Bearbeiten oder Einsehen eine 
Bestellung kontroUiert werden, ob die iiber die ID identifizierte Bestellung entweder 
dem anfragenden Benutzer gehort oder ob der Benutzer eventuell der Administrator 
ist. 

In einer modernen Anwendung mit einer Model- View-Controller (MVC)-Struktur ist 
dies relativ einfach zu bewerkstelligen, indem die Kontrollfunktion im Modell (der 
Business-Logik) verankert wird: 

public void updateOf fer (Offer of f erToBeUpdated, User callingUser) 

throws FakedldException 

{ 

if ( IhasUserRightToUpdate (of ferToBeUpdated, callingUser)) 
throw FakedldException ( "updateOf fer : " 

+ of ferToBeUpdated + " - " + callingUser) ; 
// updateOf fer .. . 

} 

Durch das Wirksamwerden der Exception wird sofort an alien Stellen im Code ange- 
zeigt, wo eine Reaktion erfolgen muss. 

Die Praxis zeigt jedoch, dass diese Kontrolle haufig ganz oder teilweise in der Con- 
troller- Schicht vorgenommen wird. Nachteile sind duplizierter Code und dass ein 
Entwickler vergessen konnte, die Kontrolle uberhaupt einzubauen. Ein Grund dafiir 
ist, dass an Sicherheit meist zu einem sehr spaten Zeitpunkt gedacht wird und Ande- 
rungen am Business-Modell dann zu aufwandig sind. Ein anderer Grund sind funktio- 
nale Erweiterungen wie z.B. die nachtragUche Einfiihrung des oben genannten Admi- 
nistrators, die eine grundsatzliche Uberarbeitung des Sicherheitskonzepts notwendig 
machen wiirde. 



Bundesamt fiir Sicherheit in der Informationstechnik 



55 



2.16 M230 POST erzwingen 



2.16 M230 POST erzwingen 



Abstract 



POST-Requests sind GET-Requests vorzuziehen oder zu erzwingen. 



Ebene 



Implementierung 



Bezug 



allgemein 



Beschreibung 



Die Ausnutzung einer XSS-Liicke zum Zwecke des Website-Spoofings ist dann am 
einfachsten durchfiihrbar, wenn der manipulierende Code einfach an den Aufruf an- 
gehangt werden kann. Ein Session Riding- Angiff lasst sich dann in einem iMG-Tag 
verstecken und unbemerkt ausfiihren. Ahnliches gilt fiir andere Angriffsformen. 

Moglich ist dies immer dann, wenn der Request von der Anwendung als GET-Request 
behandelt wird. Verwendet die Anwendung an dieser Stelle jedoch die POST-Metho- 
de, ist ein Einbau in die URL nicht mehr moglich. 

Es empfiehlt sich daher, HTML-Forms per POST-Methode zu iibertragen, so dass im 
Falle einer vorhandenen XSS-Liicke wenigstens cine kleine zusatzliche Hiirde gesetzt 
wird. Allerdings abstrahieren viele heutige Frameworks und Komfortfunktionen iiber 
der Request-Methode, d.h. sie liefern die iibergebenen Parameter, egal ob diese per 
GET oder POST geschickt worden sind. Selbst dann, wenn in der Form ein post als 
Request-Methode angegeben ist, kann ein Angreifer die Daten an die URL hangen 
und per get iibertragen, da die Anwendung nicht unterscheidet. Der Ausschluss von 
GET ist daher von der Anwendung zu erzwingen. 



Beispiel in Java 

POST-Parameter konnen in Java Servlets z.B. auf folgende Weise gelesen werden: 

protected void doPost (HttpServletRequest request, 
HttpServletResponse response) 

throws ServletException, lOException 



Beispiele 



if ( request . getMethod (). toLowerCase (). equals ( "get" ) ) 



// request abweisen 



String paraml - request . getParameter ( "paraml ") ; 



Beispiel in PHP 
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Statt von globalen Variablen $_get wird von $_post, aber niemals von $_request 
gelesen. 

$clean = $_POST [ 'par ' ] ; 
GET-Requests werden hier nicht angenommen. 

Bemerkung 

Die urspriingliche Idee hinter get und post (siehe [10]) war, zwischen sicheren und 
praktischen Anforderungen zu unterscheiden. Es muss festgestellt werden, dass die 
Anforderungen der Praxis und die hier beschriebenen Sicherheitsgesichtspunkte nicht 
mehr mit dieser Idee in Einklang zu bringen sind. Heute muss sicher nicht nur im 
Kontext des Benutzers, sondem auch im Kontext der Anwendung betrachtet werden. 
Das praktische get muss darm durch das etwas sicherere post ersetzt werden. 
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2.17 M250 Minimalitatsprinzip fiir Informationen 



Abstract Bei der Bereitstellung von Informationen ist abzuwagen zwischen der bestmdgli- 

chen Unterstiitzung des Benutzers und dem Schutz vor Angriffen. 

Ebene Semantik 

Beschreibung 

In der Regel ist es empfehlenswert, nur diejenigen Informationen bereitzustellen, die 
fiir die Anwendung notwendig sind. Dariiber tiinaus gehende Informationen konnten 
unnotige Ansatzpunkte fur eine Kompromittierung der Webanwendung liefem. 

Siehe auch M320 "Information Disclosure verhindem" 

Beispiele 

Falsch: "Bitte geben Sie ihre Benutzerkennung und die 6-stellige PIN ein" 
Richtig: "Bitte geben Sie ihre Benutzerkermung und ihre PIN ein." 



Falsch: "Das eingegebene Passwort ist falsch", falls die Benutzerkennung richtig und 
das Passwort falsch eingegeben worden sind 

Richtig: "Login nicht moglich. Benutzerkennung oder Passwort nicht korrekt." 



Falsch: "Der Benutzer existiert nicht", falls die Benutzerkennung nicht existiert. 
Richtig: "Login nicht moglich. Benutzerkennung oder Passwort nicht korrekt." 



Falsch: Eintrag auf der Hilfe-Seite: "Geben Sie hier Ihre Kundeimummer ein. Sie fin- 
den die Kundennummer rechts oben auf jeder Rechnung. Es ist die 10-stellige Zah- 
lenfolge, die mit einem R beginnt. " 

Richtig: Verzicht auf die exakten Angaben iiber Formate, Langen, Datentypen und 
Informationen, aus denen auch ein AuBenstehender Hinweise fiir deren Erlangung 
entnehmen kaim. Stattdessen "... in der Form, wie wir es Ihnen in unserem Anschrei- 
ben mitgeteilt haben." 



Der Informationsgehalt von Demoanwendungen, die offentlich zuganglich sind, ist 
unter Sicherheitsgesichtspunkten zu beurteilen und moglichst einzuschranken. 

Auf keinem Fall sind Demoanwendungen als Instanzen der Produktivanwendung be- 
reitzustellen. 
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Ausfiihrliche Erklarungen sind nur dem an der Anwendung angemeldeten Benutzer 
zu geben. 

M250.2 Hilfe-Seiten nur dem angemeldeten Benutzer zeigen 

Hilfe-Seiten, die Informationen iiber Zusammenhange von geschiitzten Anwendun- 
gen enthalten, diirfen auch nur im geschiitzten Bereicli zugreifbar sein. 
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Abstract 

Ebene Semantik 
Beschreibung 

Ein Benutzer ist in die Lage zu versetzen, Manipulationen, Falschungen und Tau- 
schungen zu erkeimen. Dazu muss aus dem Umgang mit der Website, aber auch aus 
der gesamten Kommunikation mit dem Untemehmen erkennbar sein, dass das Unter- 
nehmen bestimmte Konventionen durchgangig einhalt. Zeigt sich im Kontext einer 
Webanwendung ein auffalliges, nicht den Konventionen entsprechendes Verhalten, 
wird ein Benutzer automatisch misstrauisch und verhalt sich zuriickhaltender, so dass 
es einem Betriiger deutlich schwerer fallt, sein Ziel zu erreichen. Diese Konventionen 
soUten den Benutzem dariiber hinaus explizit mitgeteilt warden. Im Weiteren soUten 
Verhaltenshinweise fur den Fall der Verletzung der Konventionen genaimt werden. 

Das Prinz;ip, welches auch der Corporate Identity ernes Untemehmens zugrunde liegt, 
namlich die Schaffung einer unverwechselbaren Identitat und eines Wiedererken- 
nungseffektes (Content Branding), wird mit dieser MaBnahme auch auf die Online- 
Kommunikation angewandt. 

Beispiele 

Wir nennen hier, stellvertretend fiir viele weitere Gesichtspunkte, einige Beispiele: 

• Popup-Fenster sind unter dem Aspekt der Sicherheit sehr problematisch. Nach 
wie vor existiert eine Reihe von technischen Moglichkeiten (nicht nur bei Vorlie- 
gen einer XSS-Schwachstelle), ein betrugerisches Fenster so vor der Seite einer 
authentischen Website zu positionieren, dass es den Anschein hat, dass das Fens- 
ter zu der Website gehort. Ein Anbieter, der die Benutzer daran gewohnt hat, 
dass immer wieder unvermittelt Popups erscheinen, nimmt den Benutzem die 
Moglichkeit, in solch einem Fall Verdacht zu schopfen. Popups sind daher sehr 
sorgfaltig auf ihre Auswirkungen auf die Sicherheit hin zu priifen. Im Zweifel 
soUte auf deren Einsatz verzichtet werden. 

• Fur Werbebaimer gilt Ahnliches wie fiir Popups. Sie fiihren dem Benutzer immer 

wieder Uberraschendes und nicht im Kontext der Website stehendes vor Augen 
und befinden sich dabei im Vertrauenskontext der Website: Das Vertrauen, wel- 
ches dem Anbieter entgegen gebracht wird, iibertragt sich auf den Inhalt des 
Werbebanners. Besteht nicht eine starke Kontrolle iiber die Inserenten, so kann 
hier ebenfalls schnell Missbrauch entstehen. Und auch in diesem Fall gilt, dass 
eine XSS-Lucke haufig die Moglichkeit bietet, etwas zu iiberlagem oder einzufii- 
gen, das daim als Werbebaimer verstanden wird. 

• Unerwartetes und tJberraschendes soUte moglichst nicht geschehen. Dazu gehort 
auch, dass ein Benutzer nicht ohne besonderen Grund ausgeloggt wird bzw. er- 
neut zum Login aufgefordert wird (ein besonderer Grund besteht, wenn der Be- 
nutzer zu lange inaktiv gebheben ist). Ein Angreifer hatte es darm leichter, einem 
Benutzer bei Bestehen einer entsprechenden Sicherheitsliicke eine gefalschte Lo- 
gin-Seite unterzuschieben. 
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• Werden an die Benutzer E-Mails geschickt, dann sollten diese immer von ein 
und derselben E-Mail-Adresse kommen, z.B. service@meinefirma.de, niemals 

von noreply@maildienstleister . tld 



• Ein SSL-Serverzertifikat soUte niemals fehlerhaft sein. Immer wieder triffit man 
auf den Fall, dass der Servemame, wie er in der URL steht, nicht exakt mit dem 
im Zertifikat eingetragenen Namen iibereinstimmt. Dies fiihrt zu einer Wammel- 
dung des Browsers, die geeignet ist, die Benutzer nicht nur zu verunsichem, son- 
dem auch dazu fiihren kann, dass Derartiges zukiinftig als normal hingenommen 
wird. Ebenso soUte das Uberschreiten der Giiltigkeitsdauer eines Zertifikats ver- 
mieden werden. 



^ Wegcn der Icichtcn Falschbarkcit von E-Mail-Adrcsscn wiirdc auch ein Angreifer diese 
Absendeadresse benutzen. Trotzdem ist es im Sinne dieser MaCnahme wichtig, auf Durchgangigkeit der 
Konventionen zu achten. 
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2.19 M270 Verhinderung von Uberflutung / Denial-of-Service 
durch automatisierte Angriffe 

Abstract Es ist sicherzustellen, dass Ressourcen von unberechtigten Dritten nicht blo- 

ckiert werden konnen. 

Ebene Logik 

Beschreibung 

Eingangsbemerkung: Diese MaBnahme konkurriert mit MaBnahme M280. 

Grundlegendes Problem jeder MaBnahme zur Verhinderang von DoS-Angriffen ist 
die Unterscheidung eines solchen Angriffs von legitimen Zugriffen, sowie die geziel- 
te Blockierung des Angreifers, ohne legitime Benutzer in Mitleidenschaft zu ziehen. 
Wir gehen bei dieser MaBnahme davon aus, dass ein Angreifer eine Uberflutung auf 
der logischen Ebene nicht durch manuelle Browserinteraktionen ausfiihren kann, son- 
dem dazu die Zugriffe automatisieren, d.h. sich eines geeigneten Skripts oder Tools 
bedienen muss. Unter dieser Annahme reduziert sich die Aufgabe darauf, automati- 
sierte Zugriffe zu blocken und manuelle Zugriffe zuzulassen. 

Ein automatisierter DoS-Angriff kann wirksam dadurch verhindert vi'erden, dass der 
Benutzer nach Erreichen einer festgelegten Toleranzschw^elle von erlaubten Wieder- 
holungen aufgefordert wird, eine Eingabe zu tatigen, die ein Programm nicht liefem 
kann. Wird die Eingabe korrekt gegeben, kann davon ausgegangen werden, dass kein 
automatisierter Angriff stattfindet. Folgende Verfahren kommen in Frage: 



M270.1 Mustererkennung / Captchas 

Das Verfahren der Captchas (Completely Automated Public Turing Test to Tell 
Computers and Humans Apart) [11] macht sich die Uberlegenheit des Menschen ge- 
geniiber der Maschine in der visuellen Mustererkennung zunutze. Dem Benutzer wird 
ein Bild gezeigt, welches z.B. eine mit Storungen versehene Zeichenkette enthalt, die 
von einem Menschen gerade noch zu erkennen ist, von einer Maschine aber nicht 
mehr erkannt werden kann. Die korrekte Eingabe der Zeichenkette schaltet die Sper- 
rung wieder frei. 

Beim Einsatz von Captchas und der Auswahl einer Captcha-Bibliothek ist zu beach- 
ten, dass die Sicherheit dieses Verfahrens mit der maschinellen Nichtlosbarkeit der 
Aufgabe steht und fallt. Fortschritte in der Mustererkennung oder die Entdeckung 
von Algorithmen konnen diese Art von Schutz mit einem Schlag wertlos machen. 
[12] stellt eine frei verfiigbare Captcha-Klasse fur ASP zur Verfligung. Ein weiterer 
moglicher Nachteil von (schlecht gemachten oder falsch eingesetzten) Captchas ist 
die Behinderung der Barrierefreiheit, weim z.B. das Entziffem die Wahmehmung 
von Farben (Farbenblindheit!) voraussetzt. 

Beispiel 

Eine Website stellt ein Kontaktformular bereit. Dieses wird nach Ausfiillen und Ab- 
senden durch einen Benutzer per E-Mail an die dafiir vorgesehene Kontaktperson ge- 
sandt. Um zu verhindem, dass ein Angreifer mittels eines Skripts iiber das Kontakt- 
formular eine groBe Anzahl von E-Mails generiert und die Mailbox der Kontaktper- 



Bundesamt fiir Sicherheit in der Informationstechnik 



62 



2. 19 M270 Verhinderung von Uberflutung / Denial-of-Service durch automatisierte Angriffe 



son iiberflutet, enthalt das Formular ein Captcha. Der Benutzer wird aufgefordert, den 
Text, den er in der Captcha-Grafik erkennt, in das dafiir vorgesehene Feld einzutip- 
pen. Nut wenn Ubereinstimmung besteht, leitet die Anwendung die Anfrage per E- 
Mail weiter. 



M270.2 Ratselfrage 

Dem Benutzer wird eine Frage gestellt, die eine Maschine nicht interpretieren und 
damit nicht beantworten katm. Beispiele: 

"Wie lautet der dritte Buchstabe im funften Wort dieses Satzes? " 

"Geben Sie das Wort Autobaan ohne Rechtschreibfehler ein! " 

"Aus wie vielen Buchstaben besteht das erste Wort des nachsten Satzes? " 

Problem bei diesem Ansatz ist die Schwierigkeit, eine genugend groBe Anzahl von 
Fragen zu generieren. 1st die Anzahl nicht groB genug, kann ein Angreifer samtliche 
Fragen abfragen, manuell die Antworten erstellen und die Zuordnung von beidem 
dem Automaten geben, der dann anhand des Fingerprints zu jeder Frage die richtige 
Antwort findet. 

Beispiel 

Eine Zeitung bietet im offentlichen Bereich ihres Webauftritts eine Volltextsuche 
liber alle jemals erschienenen Artikeln an. Da jede Suchanfrage das System merkhch 
belastet und bereits bei rund 20 gleichzeitigen Anfragen eine deutliche Verschlechte- 
rung der Antwortzeit zu beobachten ist, sind MaBnahmen zur Verhinderung eines 
DoS-Angriffs zu ergreifen. Daher wird der Benutzer im Formular fur die Eingabe der 
Suchworte zusatzlich aufgefordert, auf eine Ratselfrage zu antworten. Da die mogli- 
che Schadenshohe als niedrig eingestuft wird, reicht es, eine Menge von 100 unter- 
schiedlichen Fragen vorzubereiten und diese zufallig in die Suchanfragen einzustreu- 
en. 
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Abstract Die Zugriffe auf Ressourcen, die durch Enumeration-Techniken verwundbar 

sind, sind zu monitoren und Wiederholungen angemessen zu begrenzen. 

Ebene Logik 

Beschreibung 

Ein Enumeration- Angriff muss zunachst erkannt werden. 1st er erkannt, ist der weite- 
re Zugriff in geeigneter Weise zu blocken oder zu behindem. Vgl. auch M270. 



2.20.1 Erkennung von Enumeration-Angriffen 

Die Erkennung eines Enumeration-Angriffs bzw. die Unterscheidung von legitimen 
Zugriffen ist haufig nicht eindeutig zu treffen. Das im Folgenden beschriebene Ver- 
fahren gibt eine grobe Richtschnur. 

Um einen Enumeration- Angriff handelt es sich, wetm der Zugriff auf eine durch Enu- 
meration-Techniken verwundbare Ressource erfolgt und zusatzHch eines oder mehre- 
re dieser Merkmale zutreffen: 

• Die Zahl der Zugriffsversuche iimerhalb einer bestimmten Zeitspanne iibersteigt 
das iibliche MaB deutlich. 

• Die Zugriffsparameter werden nach einem regelmalJigen Muster variiert. 

• Der Zugriff erfolgt immer von derselben Stelle (d.h. IP-Adresse). 

Da das zweite Merkmal leicht verschleiert werden kann, verwenden wir es im Weite- 
ren nicht, um GegenmalJnahmen daraus abzuleiten. 

Das dritte Merkmal kann ebenfalls verschleiert werden, namlich dadurch, dass die 
Zugriffe von verschiedenen IP-Adressen aus erfolgen. Der Angreifer muss dazu die 
Zugriffe iiber unterschiedliche Proxy-Server laufen lassen. Das Rotieren iiber einige 
wenige Proxys ist dabei leicht moglich und muss von einer AbwehrmaBnahme er- 
kannt werden. Theoretisch ist wegen der groBen Zahl im Internet vorhandener Proxys 
auch das Rotieren iiber eine groBe Zahl von Proxys moglich. In der Praxis ist dies je- 
doch nur unter hohem Aufwand zu erreichen, da die meisten dieser Proxys recht un- 
zuverlassig sind. So sind nur Angreifer mit ausgepragten Erfahrungen oder einer ei- 
genen Infrastruktur in der Lage, derartig vorzugehen. 

Das folgende Verfahren stiitzt sich im Wesentlichen auf das erste der drei genannten 
Merkmale: 

(1) Identifikation der Ressourcen, die verwundbar fur Enumeration sind. Dies konnen 
z.B. sein: Benutzerkennungen, SessionlDs, Dokumentennummem, usw. 

(2) Fiir jede verwundbare Ressource: Ermittlung einer Zahl N von Zugriffen inner- 
halb einer definierten Zeitspanne, die eriaubt werden kann, ohne die Ressource der 
Gefahr fiir Enumeration auszusetzen. 
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(3) Fiir jede verwundbare Ressource: Ermittlung, wieviele Zugriffe unter normalen 
Umstanden zu Spitzenzeiten in der gewalilten Zeitspanne erfolgen. 

(4) Festlegung eines Mittelwertes auf Basis von (2) und (3), der die Hoctistzahl von 
Zugriffen auf die Ressource innerhalb der gewahlten Zeitspanne darstellt. Zahlung 
diese Zugriffe, und Blockade (s.u.) aller weiteren Zugriffe. 

Je nach Anwendungsfall kann das Verfahren global auf cine Ressource, also unab- 
hangig von weiteren Parametem, angewendet werden oder aber an andere Parameter 
gekoppelt sein. 

Beispiel 1 - EnTimeration von Benutzerkennungen 

Der Registrierungsprozess einer Website erlaubt einem neuen Benutzer die Angabe 
einer eigenen Benutzerkennung. Wahlt ein Benutzer einen Namen, der bereits exis- 
tiert, so muss die Anwendung die Annahme verweigem und zur Eingabe eines neuen 
Namens auffordem. Ein Angreifer konnte nun cine Liste von Benutzemamen da- 
durch erstellen, dass er die Anmeldung systematisch mit immer anderen moglichen 
Namen durchlauft und an der Art der Antwort erkennt, ob der Benutzemame existiert 
oder nicht. 

In Schritt 1 des obigen Verfahrens wird die Wahl des Benutzemamens im Registrie- 
rungsprozess als mogliche Problemstelle fiir Enumeration identifiziert. 

In Schritt 2 wird ermittelt, dass ein Angreifer innerhalb einer Stunde mindestens 
10.000 Versuche haben muss, um durch Enumeration zu verwertbaren Ergebnissen 
zu kommen. 

In Schritt 3 wird festgestellt, dass die durchschnittliche Zahl von Anmeldungen ca. 1 
Anmeldung pro Stunde betragt und Spitzenwerte bei 10 Anmeldungen pro Stunde 
liegen. Im Schnitt erfolgen 2 Versuche, bevor ein noch freier Benutzemame identifi- 
ziert wird. Der gefragte Wert errechnet sich damit auf 20 Zugriffe pro Stunde. 

In Schritt 4 wird als Ergebnis dieser Analyse die Registrierungsprozedur mit einer 
Priifung ausgestattet, die weitere Zugriffe blockt, wenn innerhalb von 6 Minuten 
mehr als 30 Zugriffe erfolgen. 

Beispiel 2 - Passwort-Enumeration 

Eine Webanwendung verwendet als Passwort 5-stellige numerische PINs. Werden 
keine Vorkehrungen gegen Enumeration getroffen, so ist bei bekanntem Benutzema- 
men eine PIN mit durchschnittlich 50.000 Versuchen ermittelbar. 

Es liegt auf der Hand, dass bei derartig geringer Streuung ("Randomness") und 
gleichzeitig hohem Schutzbedarf der Spielraum fiir Fehlversuche sehr eng zu halten 
ist, d.h. ein Blocken bereits nach wenigen Zugriffen und auch fiir langere Dauer zu 
erfolgen hat. 

Eine MaBnahme konnte so lauten: Werden innerhalb einer Stunde fiir eine Benutzer- 
kennung mehr als 3 Fehlversuche registriert, so wird der Benutzer fiir 24 Stunden 
oder bis zum Freischalten durch den Helpdesk gesperrt. 

Da eine solche MaBnahme jedoch eine schwerwiegende DoS-Schwachstelle darstel- 
len wiirde, ist das Problem in diesem Beispiel dadurch zu losen, dass entweder Pass- 
worter mit einer deutlich hoheren Randomness, d.h. groBere Lange und Zulassung 
(fast) beliebiger Zeichen, gefordert werden oder ein Captcha (siehe M270.1) abge- 
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fragt wird. 



2.20.2 Blocken von Zugriffen 

Das Blockieren von Zugriffen muss nicht zwangslaufig bedeuten, dass der Zugriff 
(fur einen bestimmten Zeitraiun) voUstandig verboten wird. Wegen der daraus haufig 
resultierenden DoS-Schwachstelle wird dies sogar eher die Ausnahme darstellen. 
Stattdessen kommen folgende MaBnahmen in Betracht: 

• Verzogerung des Zugriffs 

• Verhinderung von automatisierten Zugriffen 

Die erste MaBnahme wird im Folgenden beschrieben. Die MaBnahmen zur Verhinde- 
rung von automatisierten Zugriffen sind dieselben wie diejenigen zur Verhinderung 
von DoS-Angriffen und sind in M270 beschrieben. 

Mafiname: Verzogerung des Zugriffs 

Ein Enumeration- Angriffkann auch dadurch verhindert werden, dass die fiir die Aus- 
fiihrung eines einzelnen Zugriffs benotigte Zeit so weit in die Lange gezogen wird, 
dass der Angreifer innerhalb eines verniinftigen Zeitraums nicht die benotigte Anzahl 
an Zugriffen durchfiihren kann. Art und Dauer der Verzogerung sind so zu gestalten, 
dass sic vom legitimen Benutzer nicht als iibermaBig storend empfunden werden. 

Beispiel 3 - Passwort-Enumeration 

Statt wie in Beispiel 2 bereits nach dem dritten fehlerhaften Versuch weitere Zugriffe 
zu unterbinden, konnte zunachst cine Verzogerung weiterer Versuche erfolgen. Nach 
dem Absenden erhalt der Benutzer die Information "Bitte warten Sie, wahrend ihr 
Passwort uberpriift wird" und erst nach Ablauf einer Minute die positive oder negati- 
ve Antwort. Ein Blockieren erfolgt dann erst nach 10 Fehlversuchen. 

Nachteil einer einfachen Implementierung der Verzogerungsstrategie ist die Tatsa- 
che, dass der realisierende Prozess oder Thread fiir die gesamte Dauer des Verzoge- 
rungsintervalls am Leben bleibt. Dies macht die Anwendung nun wiederum auf der 
Implementierungsebene fur einen DoS-Angriff anfallig. Durch entsprechend haufiges 
Auslosen von Verzogerungsthreads konnten die Systemressourcen bis zum Maxi- 
mum belastet werden. Abhilfe schafft cine entsprechend aufwandige Implementie- 
rung in Form eines eigenen Services, der in einem Thread alle wartenden Intervalle 
iiberwacht. 

Die Verzogerungsstrategie eignet sich in der Regel nicht fur Dialoge, bei denen kein 
eindeutiges Kriterium fiir den Bezug des Zugriffs auf ein einzelnes Objekt vorliegt 
(der oben genannte Fall (a)). In obigem Beispiel existiert dieses Kriterium, es ist die 
Benutzerkennung. Nur der betreffende Benutzer ist von der Verzogerung betroffen. 
Zum Schutz vor Enumeration von Benutzerkennungen wie in Beispiel 1 ist die Ver- 
zogerungsstrategie hingegen nicht oder nur schlecht geeignet, da sie globale Auswir- 
kung hatte und jeder Benutzer, der sich registrieren mochte, der Verzogerung ausge- 
setzt wiirde. 

Hinweis 

MaBnahmen gegen Enumeration- Angriffe fiihren leicht zur Herstellung von Uberflu- 
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tungsschwachstellen. Beides ist in engem Zusammenhang zu behandeln. Siehe dazu 
M270. 
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2.21 M290 Sichere Passworter erzwingen 



Abstract 



Das System akzeptiert nicht jedes vom Anwender gewiinschte Passwort, sondern 
gibt Regeln vor und priift die Einhaltung. 



Ebene 



Logik 



Beschreibung 



Bisher existieren fiir das Web keine allgemein anerkannten Verfahren und auch keine 
Standardbibliotheken zur Passwortpriifung. Auch wird haufig die Beriicksichtigung 
anwendungsspezifischer Randbedingungen erforderlich sein. Wir schlagen ein Bei- 
spiel vor, das einen guten Kompromiss aus Sicherheit, Einfachheit fur den Benutzer 
und einfacher Uberpriifbarkeit darstellt. 

Hinweis flir den Benutzer 

Bitte geben Sie hier ein selbst gewahltes Passwort ein. Das Passwort 
muss folgenden Regeln entsprechen, die Sie bitte zu Ihrem eigenen 
Schutz beachten: 

- Mindestlange : 8 Zeichen (wird uberpruft) 

- Davon mindestens 2 Ziffern oder Sonderzeichen . Erlaubt sind diese 
Sender zeichen : _,-,#,(,), @ ,§, ! (wird uberpruft) 

Passwortverf ahren 

Tipp: Setzen Sie das Passwort aus 2 falsch geschriebenen Wortern 

zusammen, die Sie mit (mindestens) 2 Sonderzeichen oder Ziffern 
verbinden. Beispiele: haus45hoof, albart##elstein, f uhss_und_ball, 
(strasssen) ban 



Tipp: Ein sicheres Passwort, das sich leicht merken lasst, erhalten 
Sie mit diesem Verfahren: Bilden Sie einen Satz und setzen Sie das 
Passwort aus den Anf angsbuchstaben in der jeweiligen GroB- oder 
Kleinschreibung zusammen. Beispiel: "Unser Haus ist das mit der 
schonen Nummer 12": UhidindsN12, "Am Sonntag stehe ich nie vor 10 Uhr 
auf " : ASsinvlOUa, "Morgen ist ein Feiertag - das ist aber schon!": 
MieF-dias ! 

Eine besonders sichere Implementierung dieses Verfahrens konnte das iibergebene 
Passwort an den Stellen aufspalten, an denen Sonderzeichen stehen, und die einzel- 
nen Fragmente darauf priifen, ob sie in einer Wortliste vorkommen, und das Passwort 
in diesem Fall als ungiiltig ablehnen. 

Zusatzlich ist dieser Hinweis angebracht: 

Bitte verwenden Sie zu Ihrer eigenen Sicherheit dieses Passwort 
nicht an anderer Stelle! 



oder 
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Abstract 



Mit Benutzerkennungen sollte sorgsam umgegangen werden. 



Ebene 



Semantik, Logik 



Beschreibung 



Beim gebrauchlichsten Authentisierungsverfahren im Web, der Authentisierung mit- 
tels Benutzerkennving und Passwort, sollte die Benutzerkennung als nicht-offentliche 
Information behandelt werden. Bei entsprechendem Schutzbedarf gilt: 

• Nicht die E-Mail- Adresse verwenden 

• Keine Schemata wie vorname . nachname verwenden. 

Es wird empfohlen, stattdessen nicht ableitbare Zeichenketten zu verwenden oder 
eine Kombination aus extemen Merkmalen mit einer nicht-erratbaren Komponente, 
Z.B. peter .meyer. 43135, kbauer . 31244. 

Zudem ist darauf zu achten, dass die Anwendung keine Hinweise iiber das Vorhan- 
densein von Benutzerkennungen gibt. Haufig anzutreffen ist diese Art der Implemen- 
tierung einer "Passwort vergessen"-Funktion: 

Der Benutzer wird aufgefordert, seine UserlD einzugeben. Ist diese korrekt, d.h. exis- 
tiert die UserlD im System, so lautet die Antwort: "Das Passwort wurde an die hinter- 
legte E-Mail- Adresse verschickt". Wurde jedoch eine nicht existierende UserlD ein- 
gegeben, so lautet die Antwort: "Dieser Benutzer existiert nicht, bitte korrigieren Sie 
Ihre Eingabe". Auf diese Weise lassen sich Benutzerkennungen durch Aufzahlen 
(Enumeration) ermitteln. Richtig ware folgende Antwort, die keine Information iiber 
das Vorhandensein einer UserlD gibt: "Das Passwort wurde an die hinterlegte E- 
Mail- Adresse verschickt, falls die eingegebene UserlD korrekt gewesen ist. Sollten 
Sie nicht in Kiirze eine E-Mail von uns erhalten, so ist dies darauf zuriickzufiihren, 
dass Sie eine fehlerhafte UserlD eingegeben haben". 

Siehe auch M280 (Enumeration verhindem). 
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Abstract 



Daten, bei denen Ausspahen verhindert werden muss, sind durch Einsatz des 
SSL-ProtokoUs zu schiitzen. 



Ebene 



Implementierung, Technologic 



Beschreibung 



Das SSL-Protokoll verschliisselt die zwischen Browser und Server ausgetauschten 
Daten und sorgt dafiir, dass vertrauliche Informationen vor dem Ausspahen auf dem 
Ubertragungsweg geschiitzt sind. Diesen Sctiutz fuhren heutige Browser soweit, dass 
auch bei einem Wechsel von einer per SSL geschutzten Seite (HTTPS) zu einer un- 
geschiitzten Seite (HTTP) - etwa dann, wenn der User auf der SSL-geschiitzten Seite 
auf einen HTTP-Link klickt - sensitive Protokollinformationen nicht weitergegeben 
werden. Dies gilt fiir: 

• Cookies (welche haufig Trager der sensitiven SessionID sind), die mit jedem 
Browser-Request mitgeschickt werden, solange dieser an denselben Host gerich- 
tet ist bzw. den Pfadrestriktionen entspricht. 

• Die Referrer-Information, welche die LTRL derjenigen Seite enthalt, auf der sich 
der geklickte Link befmdet. Dieser liefert Informationen iiber die der aktuellen 
Seite vorangegangene Seite mit all ihren GET-Parametem und der SessionID, 
falls die Technik des URL-Rev^ritings benutzt wird. 

Mit M170.3 und M170.4 wird verhindert, dass ein unter SSL gesetztes Cookie bei ei- 
nem Non-SSL-Zugriff mitgeschickt wird. 

Die Ubergabe des Referrers mit einem Non-SSL-Zugriff wird von heutigen Browsem 
dann nicht durchgefiihrt, wenn die Ausgangsseite per SSL geliefert worden ist. Line 
unerwiinschte Weitergabe wird damit wirksam verhindert. 

Falls jedoch cine Verlinkung auf cine externe Website mittels HTTPS realisiert ist, so 
wird der Referrer tatsachlich mitgeschickt. M170.1 1 ist damit unabhangig davon, ob 
es sich um eine HTTP- oder HTTPS-Site handelt, anzuwenden. Da altere Browser die 
beschriebene Sperre nicht eingebaut haben, ist M1 70.11 grundsatzlich zu beachten. 

Das SSL Server-Zertifikat stellt auBerdem sicher, dass der Hostname authentisch ist. 
D.h. es garantiert, dass der im Zertifikat angezeigte Hostname unverfalscht ist. 
SchlieBen wir den Fall aus, dass das DNS manipuliert worden ist, so garantiert das 
Zertifikat auch die Echtheit des Hosts (weim die Seite keine frames benutzt). 

Auch wenn die Anwendung selbst nicht als schutzbediirftig durch SSL eingestuft 
wird, sollten folgende Operationen verschliisselt ablaufen: 

• Registrierung 

• Login 

• Zugriff auf personliche Daten 

• Passwort-Anderung 
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• "Passwort vergessen"-Funktion 

Es soUte beriicksichtigt werden, dass auch dann, wenn die Logindaten ausschliefilich 

verschliisselt iibertragen werden, ein Eindringen in eine ansonsten unverschliisselt be- 
triebene Anwendung durch Ausspahen der SessionID moglich sein konnte. 

Bemerkung 

Achtung: SSL garantiert nicht die Echtheit einer angezeigten Webseitel 1st ein An- 
greifer in den Server eingedrungen und hat den Inhalt verandert, so wird das Zertifi- 
kat nictit verletzt. Von groBerer Tragweite als dieser Fall ist jedoch der des Cross-Site 
Scriptings: Wird eine Webseite mittels Cross-Site Scripting verandert oder durch eine 
komplett gefalschte Seite iiberdeckt, so ist dies ebenfalls nicht mit einer Verletzung 
des Zertifikats verbunden. 
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2.24 M320 Information Disclosure verhindern 

Abstract Im Folgenden werden MaBnahmen gegen eine ungewoUte Veroffentlichung in- 

terner Informationen zusammengefasst. 

Ebene Implementierung, Logik, Semantik 

Beschreibung 

Zur Einschrankung von Information Disclosure konnen folgende Ansatzpunkte her- 
angezogen werden: 

• Aus der HTML-Seite samtliche Kommentare entfemen. 

• Fingerprints entfemen: 

- Open Source Module umbenennen. 

- Server-Banner entfemen. 

- Typische Merkmale wie Meta-Tags, Form-Variablennamen usw. 
umbenennen. 

• Fehlermeldungen abfangen und dafur neutrale Fehlerseiten liefem. 

• Open Source- oder sonstige Fremdsoftware daraufhin untersuchen, ob sie im 
Fehlerfall sicherheitsrelevante Informationen ausgeben. 

• Auf richtige Serverkonfiguration achten. Siehe M370, M380, M390. 

• Enumeration verhindem. Siehe M280. 

Bemerkung 

In Bezug auf SQL-Injection ist das Abfangen von Fehlermeldungen keinesfalls aus- 
reichend. Beim Vorhandensein einer SQL-Injection-Schwachstelle konnen mit ge- 
schickter Abfragetechnik allein aus der Tatsache, dass die Anwendung in einem Fall 
eine Ausgabe, im anderen Fall eine anonyme Fehlerseite liefert, bereits weitreichende 
Schliisse gezogen werden. 
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Abstract 



Eingesetzte Standard- und Systemsoftware ist auf Known Vulnerabilities zu 
iiberwachen. Logdateien sind zu monitoren. 



Ebene 



System 



Beschreibung 



Untemehmen haben heutzutage in der Regel Prozesse installiert, die mogliche Si- 
cherheitsprobleme der im Einsatz befmdlichen Systeme iiberwachen, und bei Entde- 
ckung von Schwachstellen oder Auftreten von Sicherheitsvorfallen geeignet reagie- 
ren. Webserver und sonstige von den Webanwendungen verwendete Systeme sind in 
diese Prozesse aufzunehmen. Dabei sind auch Backendsysteme im intemen Netz ein- 
zubeziehen, sofem Webanwendungen auf sie zugreifen. Derin bei unzureichender 
Priifung der iibergebenen Daten durch die Webanwendungen kormten auch diese Sys- 
teme uber das Internet in unvorhergesehener Weise zuganglich sein. 

ZusatzUch empfiehlt sich der regelmaBige Einsatz sog. Web Application Security 
Scanner, die bei der Erkennung von Known Vulnerabilities sehr gute Dienste leisten. 

Das schnelle Einspielen eines Patches ist sicher die wirksamste SchutzmaBnahme. 
Gerade in komplexen Umgebungen ist dies jedoch wegen moglicher Seiteneffekte 
nicht immer zeitnah moglich. Ersatzweise sollte der Sicherheitsprozess dann eine Ri- 
sikoanalyse beinhalten, an deren Ende die Umsetzung angemessener altemativer 
MaBnahmen steht. Die Anwendungsverantwortlichen sollten von den Systemverant- 
wortlichen, die in der Regel fur die hier genannten Prozesse verantwortlich sind, um- 
gehend iiber die geanderte Sicherheitslage informiert werden. 



AUe Log- und Protokolldateien sollten regelmaBig kontroUiert und ausgewertet wer- 
den. Hierbei miissen neben den fachlichen Aspekten auch rechtliche, z.B. des Daten- 
schutzes, beachtet werden. Die Dateien sind insbesondere auf Auffalligkeiten zu prii- 
fen. Die folgende Liste erhebt keinen Anspruch auf Vollstandigkeit. Sie soil Anhalts- 
punkte geben, wie man Hinweise auf Sicherheitsliicken, Angriffe oder Manipulatio- 
nen erkennt: 

• GroBe der Logdatei, Anzahl der Meldungen 

• Haufigkeit von Meldungen zu bestimmten Zeiten 

• Haufigkeit von Meldungen von bestimmten Source-IPs 

• haufige fehlerhafte Anmeldeversuche 

• haufige fehlerhafte URLs 

• viele sehr ahnliche URLs (z.B. nur einzelne Zeichen verschieden) 

• ungiiltige Parameter-Namen und/oder Werten 



M335.1 



Logdateien kontrollieren 
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• offensichtlich manipulierte Daten (z.B. von Hidden-Parametem) 

• URLs mit Path Traversal 

Logdateien soUten nicht mit einem Browser betrachtet werden. Ebenso sollten die 
Logdateien der Server selbst, und nicht davon abgeleitete und speziell aufbereitete 
Dateien inspiziert werden. 
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2.26 M340 Systemkonfiguration: Benutzerkennung fiir 
Web-/Applicationserver unter UNIX 

Abstract Web- und Applicationserver soUen jeweils mit einer eigenen Benutzerkennung- 

laufen. Diese und die zugehdrige Gruppenkennung ist im Betriebssystem ent- 
sprechend zu konfigurieren. 

Ebene System 

Beschreibung 

Wenn nicht besondere Griinde dagegen sprechen, sollte jeder Web- bzw. Applicati- 
onserver mit einer eigenen Benutzer- und Gruppenkennung laufen. Bei UNIX-Stan- 
dardinstallationen wird dafur oft nobody verwendet. Davon ist abzuraten, da nobody 
auch fiir viele andere Dienste verwendet wird. Zum einen wiirden diese Dienste bei 
einem erfolgreichen Angriff auf den Webserver unnotig kompromittiert werden, und 
zum anderen konnten diese Dienste dann selbst als Ausgangspunkt fiir einen Angriff 
auf den Webserver dienen. 

Werden mehrere Instanzen eines Web- oder Applicationservers auf einem Rechner 

betrieben, dann sollte jede Instanz unter einer eigenen Benutzerkennung laufen. Unter 
UNIX ist das einfach mit dem Standard-Benutzer-ZGruppen-Konzept realisierbar. 

Die hier defmierten Benutzerkennungen miissen dann bei der Konfiguration der Ser- 
ver verwendet werden, siehe dazu M370, etc. 

Beispiele 

/etc/passwd imter UNIX/Linux: 

wwwrun : X : 4711 : 47 11 : root Web Server : /ServerRoot : /sbin/nologin 
wwwf oo : X : 4712 : 4711 : foo Web Server : /DocRoot/foo : /sbin/nologin 
wwwbar : X : 4713 : 4711 : bar Web Server : /DocRoot/bar : /sbin/nologin 

/etc/group unter UNIX/Linux: 

wwwrun : x : 4711 :wwwrun, wwwfoo, wwwbar 

Eine detaillierte Beschreibung findet sich hierzu auch in der Apache Webserver Si- 
cherheitsstudie des BSI (siehe [13]). 

Bemerkungen 

Wenn der Server Anfragen auf privilegierten Ports (1 bis 1023) bearbeiten soil, dann 
muss der Serverprozess unter UNIX als Benutzer root gestartet werden. In der Kon- 
figuration der Server (siehe z.B. M370) wird dann festgelegt, als welcher Benutzer 
der Prozess wirklich lauft. 

Das weit verbreitete Apache-Modul mod peri wird z.B. mit der PeriRequire Direc- 
tive in httpd. conf initialisiert. Diese Initialisierung wird als Benutzer root durchge- 
fuhrt, damit konnten dann auch alle weiteren Berechtigungen, z.B. in diesem Modul 
initialisierte Datenbankverbindungen, an root gebunden sein. Kann der Server mit 
einem nicht-privilegierten Port arbeiten, dann kann der Prozess sofort unter der ge- 
vninschten Benutzerkennung gestartet werden. Fiir sehr sicherheitskritische Anwen- 
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dungen sollte man also erwagen, einen entsprechenden Port zu verwenden. 
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2.27 M350 Systemkonfiguration: Dateiberechtigungen 



Abstract Verzeichnisse und Dateien miissen mit Zugriffsrechten ausgestattet werden, die 

nur dem autorisierten Benutzer die erforderlichen Berechtigungen geben 

Ebene System 

Beschreibung 

Die Dateien und Verzeichnisse des Web- bzw. Applicationserver werden mit entspre- 
chenden Berechtigungen versehen. Dabei ist zwischen den Daten und Programmen 
fur den Dienst selbst (z.B. Programme, Skripte, Konfiguration) und den Anwen- 
dungsdaten (z.B. /DocumentRoot) zu unterscheiden. 

Die Berechtigungen werden unter Voraussetzung von M340 gesetzt. 

Eine detaillierte Beschreibung findet sich hierzu auch in den Apache- und IIS- 
Webserver-Sicherheitsstudien des BSI (siehe [13][14]). 

Beispiele 

Datei- und Verzeichnisberechtigungen'* fur UNIX/Linux: 



chown -R wwwrun : wwwrun /ServerRoot 



chown root: root 
chown root: root 
find /ServerRoot 
find /ServerRoot 
find /ProgramRoot 
find /ProgramRoot 
find /DocumentRoot 
find /DocumentRoot 



/ ServerRoot 
/ ServerRoot/log 
type d -exec chmod 2750 {} \; 

f -exec chmod o-x,o-r,o-w {} \; 
d -exec chmod 2550 { } \; 
f -exec chmod 550 {} \; 
■exec chmod 2550 {} \; 
exec chmod 440 {} \; 



-type 

-type d 

-type f 

-type d 

-type f 



Entgegen der bei Apache iiblichen Ablage der Logdateien in /var/iog/httpd wer- 
den im obigen Beispiel die Logdateien in /serverRoot/iogs erwartet. Dort soUte 
nur root Lesen und Schreiben konnen. 



Achtung: die Reihenfolge obiger Kommandos ist wichtig. 

Datei- und Verzeichnisberechtigungen fur Windows: 

cd ServerRoot 

cacls.exe . /T /E /R TERMINALSERVERBENUTZER 
cacls.exe . /T /E /R Benutzer 
cacls.exe . /T /E /G wwwrun : F 
cacls.exe . /T /E /G wwwgrp:R 



Der TERMINALSERVERBENUTZER ist hicr cxplizit aufgefuhrt, weil dieser Benutzer von 
Windows automatisch angelegt und in verschiedenen Gruppen eingetragen wird, 
wenn die Terminaldienste installiert sind. 



Das Unix/Linux Programm chmod wird hier einmal mit numerisclien Rechten (550) und einmal mit 
symbolisciien Recliten (o-x) verwendet. I.d.R. ist die Vcrwcndung der numerisclien Rechte siciierer. 
Manchmal miissen aber besondere Berechtigungen, die z.B. bei der Installation vergeben wurden, 
beibehalten werden. Dann muss man mit den symbolischen Rechten arbeiten. 
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Bemerkungen 

Unter UNIX/Linux lassen sich die Berechtigungen noch restriktiver setzen. Durch die 
MaBnahme M370 und M340 ist sichergestellt, dass der Webserver unter seiner eige- 
nen Benutzerkennung lauft, dann sind nur noch Berechtigungen fur den Besitzer der 
Verzeichnisse und Dateien, nicht aber fur die Gruppe notig. Statt 2750 und 550 kann 
dann 27 00 und 500 bei chmod verwendet werden. 

Unter Windows ist es schwieriger, ein allgemein giiltiges Vorgehen zu definieren, da 
die existierenden Berechtigungen stark von den Systemeinstellungen in Windows 
selbst abhangen. Zusatzlich muss man immer mit caics . exe iiberpriifen, welche zu- 
satzlichen Berechtigungen vergeben sind und diese dann ebenfalls entsprechend an- 
dem. 



M350.1 Spezielle Dateiberechtigungen 



Beispiele 



Fiir besondere Anwendungsfalle miissen zum oben Gesagten abweichende Zugriffs- 
rechte fur Verzeichnisse und Dateien definiert werden. 

Besonders strikte Berechtigungen 

AUe statischen Inhalte (also Dateien, die nur lesend gebraucht werden) soHten mit 
sehr strikten Zugriffsberechtigungen ausgestattet werden. Statisch in diesem Sinne 
sind auch immer alle Programm- und Konfigurationsdateien. 

In solchen Umgebungen kann es sinnvoll sein, dass alle Verzeichnisse und Dateien 
dem Benutzer root gehoren. Dann miissen sie von der Gruppe lesbar sein, wobei der 
Benutzer des Webservers Mitglied dieser Gruppe sein muss. 

Eigene Benutzerkennung pro Instanz 

Programm-Datei- und Verzeichnisberechtigungen fur UNIX/Linux: 

find /ProgramRoot -type d -exec chmod 2500 { } \; 

find /ProgramRoot -type f -exec chmod 500 {} \; 

find /DocumentRoot -type d -exec chmod 2500 { } \; 

find /DocumentRoot -type f -exec chmod 400 {} \; 

Berechtigungen bei mehreren Instanzen 

Bei mehreren Instanzen derselben Software (also z.B. eine Installation der Webserver 
Software, von der aber mehrere Prozesse gestartet werden) ist es besonders wichtig, 
die Berechtigungen der Datenzugriffe gegeneinander abzusichern, da die Software 
fur jede Instanz die gleichen Berechtigungen hatte. Die Dienste laufen unter der Be- 
nutzerkennung wwwf oo bzw. wwwbar, darum muss die Software (/ServerRoot/) fur 
die Gruppe lese- und ausfuhrbar sein. Die Daten diirfen aber nur fur den Besitzer les- 
bar sein. Die oben unter M350 genannten Empfehlungen sind daher wie in den fol- 
genden Beispielen angegeben, abzuandem. 



Programm-Datei- und Verzeichnisberechtigungen unter UNIX: 
(I) Zunachst muss die Software fur die Gruppe lese- und ausfuhrbar sein: 
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# (1) ServerRoot fur die Gruppe 
chown -R wwwrun : wwwrun /ServerRoot 

find /ServerRoot -type d -exec chmod 2750 {} \; 
find /ServerRoot -type f -exec chmod 550 {} \ ; 

(2) Dann wird fur jede Instanz das Verwaltungsverzeichnis (fiir Logdateien, etc.) mit 
Berechtigungen ausschlieBlich fur den Benutzer der Instanz versehen 

# (2) Verwaltungsverzeichnis pro Instanz 
chown wwwfoo : wwwrun /ServerRoot/wwwf oo 
chown wwwbar : wwwrun /ServerRoot/wwwbar 

find /ServerRoot/wwwf oo -type d -exec chmod 2700 {} \; 
find /ServerRoot/wwwbar -type d -exec chmod 2700 {} \; 

(3) , (4) /ProgramRoot fuT die Programme und Skripte der Instanz ist ebenso wie 
/DocumentRoot mit Berechtigiuigen ausschlieBlich fur den Benutzer der Instanz zu 
versehen. 

# (3) ProgramRoot pro Instanz 
chown wwwrun : wwwrun /ProgramRoot 
chmod 2550 /ProgramRoot 

chown -R wwwfoo : wwwrun /ProgramRoot/ foo 

find /ProgramRoot/f oo -type d -exec chmod 2500 {} \; 

find /ProgramRoot/f oo -type f -exec chmod 400 {} \; 

chown -R wwwbar : wwwrun /ProgramRoot/bar 

find /ProgramRoot/bar -type d -exec chmod 2550 {} \; 

find /ProgramRoot/bar -type f -exec chmod 400 { } \; 

# (4) DocumentRoot pro Instanz 
chown wwwrun : wwwrun /DocRoot 
chmod 2550 /DocRoot 

chown -R wwwfoo :wwwrun /DocRoot/foo 

find /DocRoot/foo -type d -exec chmod 2500 {} \; 

find /DocRoot/foo -type f -exec chmod 400 {} \; 

chown -R wwwbar : wwwrun /DocRoot/bar 

find /DocRoot/bar -type d -exec chmod 2550 {} \; 

find /DocRoot/bar -type f -exec chmod 400 {} \; 

Bemerkungen 

Bei Vorliegen von mehreren Instanzen muss man sich entscheiden, ob die zugehori- 
gen Konfigurationsdateien im gruppenzugangUchen /ServerRoot Hegen oder in dem 
Verwaltungsverzeichnis der Instanz. In beiden Fallen sollten die Konfigurationsdatei- 
en nur lesbar fur den Benutzer sein (chmod 4 00 in UNIX). 
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2.28 M360 Serverkonfiguration: Environment und Startup 



Abstract Serverprozesse soUen mit einem genau definierten Environment ausgestattet 

werden. Startup-Skripte miissen dieses gewahrleisten und auch genau den von 
ihnen selbst gestarteten Server beenden konnen. 

Ebene System 

Beschreibung 

Der Startkontext eines Servers ist sicherheitsrelevant. So erbt ein Prozess von seinem 
aufrufenden Parent-Prozess (in UNIX meist eine Shell) das gesamte Environment. Es 
gilt also, dieses Environment zu bereinigen bzw^. voUstandig neu zu initialisieren. 

Da die meisten Dienste mit einem rc-Skript gestartet werden, ist genau dies die richti- 
ge Stella fur die Anpassungen. 

Fiir Start und Stopp eines Server-Dienstes muss ein entsprechendes Startup-Skript er- 
stellt w^erden. Dabei sind die Vorgaben bzgl. Environmentvariablen zu beachten. 
Weiter ist wichtig, dass der Dienst ordnungsgemaB beendet wird. Einige Produkte 
bringen dazu ihre eigenen Skripte mit, diese sind dann zu iiberpriifen. Andere Pro- 
dukte haben keine Skripte, fur sie konnte das folgende Beispiel verwendet werden. 

Beispiele 

rc-Skript fur Apache mit PHP auf UNIX/Linux. 

#!/bin/sh 

# (1) Environmentvariablen definieren 
PATH=/bin : /usr/bin : / ServerRoot/bin : / opt/php/bin : 

FS=" " # space, h-tab, newline 

SHELL=/bin/sh 

# (2) alle anderen loschen 

_R0= ' BASH_VERSINFO | EUID | PPID | UID | SHELLOPTS ' 
_0K= ' IFS I SHELL | PATH | LANG | TZ ' 

unset ~\set| /bin/awk -F= ' Z'" ( ' $_R0 ' | ' $_0K' ) {next } {printf " 

unset _R0 _0K 

USER=nsuser 

HOME=/tmp 

PHPRC=/ServerRoot/conf 

# (3) start/stop des Dienstes 

\cd /ServerRoot/bin/ 
case in 
' start ' ) 

/bin/echo -n "starting http ... " 
./httpd -f /ServerRoot/conf /httpd. conf && \ 
/bin/echo httpd started 
' stop' ) 

/bin/echo -n "stopping httpd ... " 

pid=Vbin/ps -ef|/bin/awk ' ( $8==" . /httpd" &&$3==1 ) {printf " $2}'^ 
if [ -n "$pid" ] ; then 

/bin/kill $pid && /bin/echo stopped 

else 

/bin/echo httpd not running 

fi 
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esac 
exit $? 

Erklarung des Beispiels: 

(1) Reduzierung des Environment auf das Notwendigste: PATH, SHELL, USER, 
HOME, FS, PHPRC 

(2) Einige Shells haben read-only Variablen; um Fehlermeldungen in diesem Skript 
zu vermeiden, diirfen sie nicht geloscht werden. Diese Liste der Variablen ist je nach 
Shell anzupassen. 

(3) Zum Starten des Servers wird kein voUstandiger Pfad verwendet, dieser ist nur 
diesem Skript bekannt, und kann somit nicht einfach mit ps festgestellt werden 
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2.29 M370 Serverkonfiguration: Webserver 



Abstract Ein Webserver muss in Bezug auf Benutzerkennung, Zugriffsrechte auf Prozes- 

se, Verzeichnisse und Dateien, Fehlerausgaben und Protokollierung sicher kon- 
figuriert werden. 

Ebene System 

Beschreibung 

Nach der Installation des Servers miissen Sicherheitseigenschaften angepasst werden. 
Die weiteren MaBnahmen gehen davon aus, dass die Software voUstandig installiert 
ist. Es wird welter vorausgesetzt, dass alle zum Betrieb der Applikation nicht relevan- 
ten Telle, wle z. B. Samples, Manuals und Testseiten, berelts entfemt sind. 

Elne sichere Konfiguratlon umfasst dann mindestens folgende 4 Konzepte: 

Eingeschrankte Benutzerkennung und Zugriffsrechte 

Die Benutzer- und Gruppenkennung muss bereits im Betriebssystem vorgesehen sein, 
slehe dazu M340, M350. Diese niedrig-privilegierten Kennungen werden dann be- 
nutzt, um den Serverprozess auszufuhren. Dies reduziert die Gefahr, dass durch einen 
kompromittlerten Server weltere Telle des Systems gelesen oder verandert werden 
konnen. 

Keine unnotige Verof fentlichung interner Inf ormationen , 
Fehlerausgabe 

Wenn ein Server sich mit einem ausfiihrlichen Server-Banner meldet, dann lasst sich 
daraus unmlttelbar auf ggf. vorhandene Schwachstellen schlleBen. Fehlt dagegen eine 
ausfiihrliche Information uber den Typ des Servers, dann mussten entsprechende 
Tests durchgeflihrt werden. Ein Abschalten des Server-Banners und anderer Informa- 
tlonen erhoht die Sicherheit. Nicht zu vergessen sind die Fehlerseiten des Webser- 
vers, die bel bestimmten Fehlem automatlsch vom Webserver ausgeliefert werden; 
auch sie sind so zu gestalten, dass sie keine weiteren Informationen iiber das System 
imd den Webserver bekannt geben (Fehlerausgaben der Applikation werden in M250 
behandelt). 

Getrennte Verzeichnisse fur Programme und Daten 

Die Verzeichnisse, die ein Webserver fiir Programme, Skripte und Daten (statische 
Seiten) verwendet, sind zu trennen, so dass z.B. Zugriffe auf Seiten keine Skripte im 
Sourcecode ausliefern. 

Gute Protokollierung 

Die Protokollierung 1st so zu konfigurleren, dass jederzelt alle Aktionen (Zugriffe) 
und Transaktionen einsehbar sind. Ein Administrator muss in der Lage sein, Angriffe, 
Angriffsversuche, und Verwendung von problematischem Code durch Auswertung 
der Logdateien zu erkennen. Slehe auch M335.1 . 

Beispiele 

Die folgenden Beispiele betrachten die http . conf fiir Apache. Weltere detalllierte 
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Beschreibungen und Beispiele finden sich in der Apache Webserver Sicherheitsstudie 
desBSI (siehe[13]). 

(1) Jede Webserver-Instanz hat eine eigene Benutzer- und Gruppenkennung, mit der 
der Serverdienst gestartet wird. Die Gruppenkennung kann mit der anderer Dienste 
(z.B. Applicationserver) geteilt werden, weim beide auf die gleichen Daten und/oder 
Verzeichnisse zugreifen miissen. 

# (1) Benutzer-, Gruppenkennung 
User wwwrun 

Group wwwgrp 

(2) Die Server-Signatur und anderer Informationen im Apache werden abgeschaltet, 
um die Sicherheit zu erhohen. 

# (2) Server Signatur 
ServerSignature Off 
ServerTokens ProductOnly 
ExtendedStatus Off 

(3) Die Verzeichnisse fiir die Server-Software und die Dokumente sowie 
Programme/Skripte des Webservers sind strikt getrennt. Idealerweise sind mindestens 
fiir DocumentRoot und serverRoot jeweils eigene Partitionen vorgesehen. 

# (3) Verzeichnisse 
ServerRoot /ServerRoot 
DocumentRoot /DocumentRoot/htdocs 
ScriptAlias /cgi-bin/ "/ProgramRoot/" 
<Directory "/ ProgramRoot "> 

Options None 
AllowOverride None 
Order allow, deny 

Allow from all 
<LIMIT GET POST> 

Order allow, deny 

Allow from all 
</LIMIT> 

<LIMITExcept GET POST> 
Order deny, allow 

Deny from all 
</LIMIT> 
</Directory> 

(4) Die Zugriffsrechte fiir DocumentRoot werden zunachst sehr restriktiv gesetzt. Mit 
Deny from all ist sichcrgestellt, dass nur noch Zugriffe erlaubt sind, die mit einem 
entsprechenden Allow from . . freigegeben wurden. Die LiMiT*-Werte sind entspre- 
chend den Anforderungen anzupassen. Danach werden die Zugriffsrechte fiir den 
physikalischen Pfad zu DocumentRoot explizit gesetzt. Insbesondere werden in 
DocumentRoot kcine ausfuhrbarcn Dateien (z. B. CGI) erlaubt, und in Server-Side- 
Includes (SSI) ist es nicht moglich, exteme Programme aufzurufen. AuBerdem sind 
die Zugriffsmethoden auf head, get und post beschrankt. 

# (4) Berechtigungen fiir Verzeichnisse 
<Directory /> 

Options None 
AllowOverride None 
LimitRequestBody 204800 
LimitRequestFields 50 
Order deny, allow 

Deny from all 
</Directory> 
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<Directory " /DocumentRoot/htdocs " > 

Options +FollowSymLinks -ExecCGI -IncludesNOEXEC 

AllowOverride None 
<LIMIT HEAD GET POST> 
Order allow, deny 

Allow from all 
</LIMIT> 

<LIMITExcept HEAD GET POST> 

Order deny, allow 

Deny from all 
</LIMIT> 
</Directory> 

(5) Die Konfigurationsdateien des Webservers miissen gegen unberechtigten Zugriff, 
vor allem iiber URLs, geschiitzt werden. Dazu wird der Name der Dateien festgelegt, 
und anschlieBend der Zugriff verweigert. Weiter wird der Zugriff auf haufig verges- 
sene Dateien verweigert, diese werden an ihren Dateinamenerweiterungen erkaimt. 



# (5) Zugriff sschutz auf bestimmte Dateien 
AccessFileName .htaccess 
<Files ~ "'-\.ht"> 

Order allow, deny 

Deny from all 

Satisfy all 
</Files> 

<FilesMatch "\ . (old | bak | tar | tgz | gz | inc| cf g | conf ) $"> 

Order allow, deny 

Deny from all 
</Files> 



(6) Zugriff auf Benutzerverzeichnisse wird deaktiviert. 

# (6) Zugriff sschutz auf Benutzerverzeichnisse 
UserDir disabled 

# Oder 

UserDir /DocumentRoot/htdocs 



(7) Die GroBe der Daten, die ein Benutzer zum Server schicken kann, werden auf 
einen vemiinftigen Wert begrenzt, um DoS-Angriffe zu verhindem. Welcher Wert 
verniinftig ist, entscheidet die Applikation, also z.B. "maximale GroBe von Dateien, 
die gesendet werden" oder "maximale GroBe der Parameter aus Formularen". 

# (7) GroBe von Uploads begrenzen 

SetEnvIf Content-Length " [ 1-9 ] [ 0-9] { 4 , } " too_large=l 
<Loction /upload> 

Order Deny, Allow 

Deny from env=too_large 

ErrorDocument 403 /DocumentRoot/htdocs/upload_too_large . html 

</Location> 



(8) Auch die Logdateien liegen in einem Verzeichnis, welches nicht iiber 
DocumentRoot erreicht werden kann. Empfohlene Zugriffsrechte fiir dieses Verzeich- 
nis und die Dateien siehe M340, M350, M350.1. 



# (8) Log- und sonstige Dateien 
LockFile /ServerRoot /var /lock 

PidFile /ServerRoot/var/pid 
ScoreBoardFile /ServerRoot/var/ score 
ErrorLog /ServerRoot/ log/ error_log 

CustomLog /ServerRoot/log/ access_log 
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Bemerkung 

zu (6): mit disabled alleine ist zwar der Zugriff nicht mehr moglich, aber der 
Webserver gibt durch unterschiedliche Fehlerseiten noch bekannt, ob der User exis- 
tiert oder nicht. Will man vermeiden, dass Enumeration der Benutzemamen erfolgt, 
dann ist die zweite Variante zu wahlen. 

zu (7): man beachte, dass die Verwendung der Environmentvariablen 
CONTENT LENGTH in dcr AppHkation nicht verhindert, dass groBe Datenmengen ge- 
sendet werden, da der Webserver die Daten zuerst vollstandig annimmt, bevor 
coNTENT_LENGTH gesctzt wird, und dann die Applikation aufgerufen wird. 



M370.1 Namenserweiterungen 

Ein Webserver erkennt an der Dateinamenserweiterung (File-Extension), um welche 
Art von Datei es sich handelt, und wie diese (an den Browser) ausgeliefert wird. Fehlt 
eine Zuordnung, dann darf der Webserver die angeforderte Datei nicht ausliefem. 
Haufig verwenden Zusatz-Programme wie z.B. Perl oder PHP bestimmte Includeda- 
teien. Um zu verhindem, dass diese unbeabsichtigt gelesen werden, ist deren Endung 
so zu wahlen wie die des Programms/Skripts, welches die Datei inkludiert. Dadurch 
wird automatisch verhindert, dass solche Dateien irrtiimlich (z.B. nach Anderung der 
Serverkonfiguration) als Text ausgeliefert werden. 

Beispiele 

# (1) allgemein 
global . inc . cgi 

# (2) Perl 
global . inc . pi 

# (3) PHP 
global . inc . php 

# (4) ASP 
global . inc . asp 

Bemerkung 

Diese Konfiguration verhindert nicht, dass die Datei direkt via URL aufgerufen wird. 
Ein solcher direkter Aufruf einer Includedatei karni zu einem nicht vorhersehbaren 
Verhalten fiihren, da die Funktion der meisten Includedateien an bestimmte Voraus- 
setzungen geknupft ist, die beim direkten Aufiaif unter Umstanden nicht gegeben 
sind. Um den Direktaufruf vollstandig zu verhindem, miissen die Includedateien in 
ein eigenes Verzeichnis auBerhalb von DocumentRoot bzw. ProgramRoot gelegt wer- 
den. Die Anwendungen sind entsprechend anzupassen. 



M370.2 Fehlerseiten 

Ein Webserver liefert beim Erkennen von Fehlersituationen automatisch entsprechen- 
de Seiten, meist passend zum Fehler, aus. Diese Seiten konnen (meist) frei gestaltet 
werden. Dabei ist darauf zu achten, dass keine unnotigen Informationen in der Feh- 
lerseite enthalten sind, insbesondere keine Pfadnamen. AuBerdem ist sicherzustellen, 
dass keine Eingabedaten (URL oder HTTP-Header) ausgegeben werden. Wenn die 
Ausgabe von solchen Parametem doch notwendig ist, dann miissen diese entspre- 



Bundesamt fiir Sicherheit in der Informationstechnik 



85 



2.29 M370 Serverkonfiguration: Webserver 



chend gefiltert werden, siehe entsprechende Data Validation MaBnahmen M100 bis 
M150 
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Abstract Ein Datenbankserver muss in Bezug auf Benutzerkennung, Zugriffsrechte auf 

Datenbanken, Tabellen, Stored Procedures und Tabelleninhalte sicher konfigu- 
riert werden. 

Ebene System 

Beschreibung 

In den MaBnahmen M340 und M350 wurde bereits erklart, wie die Prozesse, Ver- 
zeichnisse und Dateien mit entsprechenden Benutzerkennungen zu versehen sind, so 
dass der mogliche Schaden bei einem Eindringen in die Webanwendung durch eine 
zweite Verteidigungslinie begrenzt wird. Dasselbe Prinzip ist durch entsprechende 
Konfiguration auch bei Datenbanken anzuwenden. Diese Konfiguration umfasst 
mindestens folgende 4 Konzepte: 

Eigener Administrationsbenutzer 

Traditionell verwalten Datenbanken ihre eigenen Benutzer. Diese sind unabhangig 
von den Benutzem des Host-Systems. Fiir die Benutzerverwaltung verwenden die 
meisten Datenbanksysteme eine eigene Tabelle oder sogar eine eigene Datenbank. 
Zugriff auf diese Tabelle hat normalerweise nur der voreingestellte Benutzer root 
(oder administrator oder sa). Dieser Benutzer hat automatisch auch auf alle ande- 
ren Datenbanken Zugriff. Er darf nicht von der Applikation fiir Zugriffe auf ihre Da- 
ten verwendet werden. 

Sicherer Zugang und Passwort fiir Administrationsbenutzer 

Fiir den Administrationsbenutzer ist ein Passwort zu setzen. AuBerdem soUte dieser 
nur vom localhost aus zugreifen diirfen. 

Systemtabellen und Systemfunktionen sichern 

Zugriff auf die Systemtabellen und Systemfunktionen (z.B. Stored Procedures) miis- 
sen soweit wie moglich verboten werden. 

Applikationsspezif ische Benutzer mit jeweils eigenem 
Passwort 

Wenn auf eine Datenbank-Instanz mehrere Applikation zugreifen, daim ist fiir jede 

Applikation eine eigene Benutzerkennung zu verwenden. Diese einzelnen Benutzer 
sollten nur auf ihre eigenen Daten zugreifen konnen (sofem die Applikation nichts 
anderes erfordert). 

Beispiele 

MySQL 

Die folgenden Beispiele betrachten eine MySQL Datenbank: 
(1) Eigener Administrationsbenutzer 

Im AUgemeinen ist eine Administratorkeimung bereits vorhanden, sie sollte zur Si- 
cherheit aber iiberpriift werden: 
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USE mysql; 

SELECT * FROM user WHERE User= ' root ' ; 

(2) Sicherer Zugang und Passwort fur Administrationsbenutzer 

USE mysql; 

UPDATE user SET Host= ' localhost ' WHERE User= ' root ' ; 

UPDATE user SET Password=password ( ' geheim' ) WHERE User= ' root ' ; 

(3) Systemtabellen und Systemfunktionen sichem 

Bei MySQL miissen hier nur die Rechte in der mysql . user Tabelle gesetzt werden: 



USE mysql; 



UPDATE 


user 


SET 


Select priv='N' 


WHERE 


NOT 


(User= 


root ' ) 


UPDATE 


user 


SET 


Insert priv='N' 


WHERE 


NOT 


(User= 


root ' ) 


UPDATE 


user 


SET 


Update priv='N' 


WHERE 


NOT 


{User= 


root ' ) 


UPDATE 


user 


SET 


Delete priv='N' 


WHERE 


NOT 


(User= 


root' ) 


UPDATE 


user 


SET 


Create priv='N' 


WHERE 


NOT 


(User= 


root' ) 


UPDATE 


user 


SET 


Drop priv='N' 


WHERE 


NOT 


{User= 


root' ) 


UPDATE 


user 


SET 


Reload priv='N' 


WHERE 


NOT 


(User= 


root ' ) 


UPDATE 


user 


SET 


Shutdown priv='N' 


WHERE 


NOT 


(User= 


root ' ) 


UPDATE 


user 


SET 


Process priv='N' 


WHERE 


NOT 


(User= 


root ' ) 


UPDATE 


user 


SET 


File priv='N' 


WHERE 


NOT 


{User= 


root ' ) 


UPDATE 


user 


SET 


Grant priv='N' 


WHERE 


NOT 


(User= 


root' ) 


UPDATE 


user 


SET 


Index priv='N' 


WHERE 


NOT 


(User= 


root' ) 


UPDATE 


user 


SET 


Alter priv='N' 


WHERE 


NOT 


{User= 


root' ) 



(4) Applikationsspezifische Benutzer mit jeweils eigenem Passwort 



Zunachst werden alle schwach gesicherten Benutzer geloscht: 

USE mysql; 

DELETE FROM user WHERE Host='' OR Host='%'; 

DELETE FROM user WHERE User='' OR User='%' OR Password=''; 

DELETE FROM db WHERE Host='' OR Host='%'; 



USE mysql; 

INSERT INTO user SET 

Host= ' www . domain . tld ' , User= ' wwwsql ' , Password=password ( ' sicher ' ) ; 
INSERT INTO db SET Host= ' www . domain . tld ', User= ' wwwsql ', Db= ' www ' ; 

Microsoft SQL Server 

(3) Systemtabellen und Systemfiinktionen sichem 

BeispieUiaft sei erklart, wie in der Registry die Verwendung der xp_* (z. B. 
xp_cmdsheii) Stored Procedures abgeschaltet werden: 

HKLM\Software\Microsoft\Microsoft SQL Server\<Instanz 
Name>\Providers\DisallowAdhocAccess 

Oder: 



HKLM\Sof tware\Mi cro soft \MS SQLServer \ [ccc] MSSQL\DisAllowAdhocAccess 

Fur eine sichere Konfiguration des Microsoft SQL Server sei auf die ausfuhrliche 
Dokumentation von Microsoft selbst oder auf [15] verwiesen. 
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Bemerkungen 

Eine haufig anzutreffende Empfehlung zur sicheren Konfiguration des Datenbank- 
servers ist, den Server auf demselben Rechner wie den Web- und/oder Applications- 
erver zu betreiben. So konnten dann Remotezugriffe auf den Datenbankserver ver- 
mieden warden; die Webanwendung konnte via localhost zugreifen. Diese Empfeh- 
lung bringt jedoch Gefahren mit sich. Zum Beispiel wird vergessen, dass der Daten- 
bankserver seine Datenbanken und Tabellen als Dateien ablegt. Diese Dateien sind 
dann wiederum Angriffen auf das Dateisystem ausgesetzt, was die Konfiguration des 
Datenbankservers nicht effektiv verhindem kann. Mit einer XSS-, Command-Injecti- 
on- oder SQL-Injection-Schwachstelle konnten die Datenbankdateien selbst gestoh- 
len oder manipuliert werden. Wenn immer moglich sollten die verschiedenen Diens- 
te (hier Webserver und Datenbankserver) auf getrennten Rechnem laufen, siehe dazu 
M400 (Web Application Isolation). 
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2.31 M390 Serverkonfiguration: PHP-Umgebung 



Abstract PHP bietet eine Vielzahl von Konfigurationsmoglichkeiten, um bekannten 

Schwachstellen zu begegnen oder sie auszuschlieBen. 

Ebene System 

Beschreibung 

Die Konfiguration einer sicheren PHP-Umgebung ist auch fur erfahrene Administra- 
toren eine Herausforderung. PHP ist zwar nicht prinzipiell unsicher, jedoch ist die 
Grundkonfiguration eher auf maximale Benutzbarkeit ausgelegt. 

Leider fehlt PHP ein globaler Schalter, ahnlich wie tainted mode in Perl, so dass man 
viele Einstellungen entweder selbst in der Konfigurationsdatei php . ini oder im Ap- 
plikationscode vomehmen muss, php . ini enthalt viele sicherheitsrelevante Konfigu- 
rationsoptionen, die auch meist gut dokumentiert sind. 

Zu den problematischen Optionen gehort register_giobais=on. Obwohl seit Versi- 
on 4.2.0 standardmaBig off, wird sie oft wieder auf on gesetzt, um altere Anwen- 
dungen nicht anpassen zu miissen. Wahrend die Einstellung on haufig zu Schwach- 
stellen fiihren kann, fordert register_giobais=of f die genauere Priifung von Ein- 
gabedaten durch den Programmierer (s.a. M150 Data Validation). 

Im Weiteren problematisch sind die Anweisungen include and require. Bei un- 
sachgemaBer Nutzung konnen sie zum Nachladen von Dateien aus beliebiger Quelle 
missbraucht werden. 

PHP bietet auBerdem eine einfache API zur Verwaltung von Sessions. Jedoch gibt es 
in der Standardkonfiguration eine Reihe von Problemen, insbesondere in Bezug auf 
die Nutzung von SessionlDs. 

Im Folgenden werden die wichtigsten Einstellungen fiir die php . ini erklart. 

Beispiele 

(1) Server Signatur und Logdateien 

Abschalten der Server-Signatur und anderer Informationen, aber ProtokoUierung al- 
ler Fehler in der Logdatei: 

[PHP] 

expose_php 
display errors 
error_reporting 

(2) Variablen sichem 

PHP sucht in verschiedenen Quellen nach der Belegung von Variablen. Die Suchrei- 
henfolge ist standardmaBig festgelegt. Die Suche ist beendet, sobald die gewiinschte 
Variable gefunden ist. Ein Programmierer muss selbst sicherstellen, dass die Varia- 
ble aus der richtigen Quelle gelesen wird. PHP kann die Liste der fur die Anwen- 
dung erlaubten Quellen vorgeben. Dadurch lassen sich Manipulationsversuche deut- 
lich einschranken. Nimmt man an, dass das Environment gemaB iVI360 definiert ist, 
und dieses nicht mehr manipuliert werden kann, dann ist folgende Reihenfolge sinn- 
voU: E - Environment, p - POST, s - Server fur variabies_order: 



= Off 
= Off 
= E ALL 
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register_globals = Off 
variables_order = "EPS" 

(3) Definieren der Verzeichnisse fur Includes und Uploads 

Einige PHP-Funktionen konnen Dateien aus beliebigen, auch nicht-lokalen Quellen 
einbinden. Diese Moglichkeit zur Einbindung nicht-lokaler Dateien sollte mit 
allow uri fopen=off deaktivlert warden. Ebenso sollte festgelegt werden, aus 
welchen Verzeichnissen Include-Dateien eingebunden werden durfen, bzw. in wel- 
chen Verzeichnissen Daten abgelegt werden durfen. 

allow url fopen = Off 

saf e_mode_include_dir = /ServerRoot/PHP-includes/ 
upload_tmp_dir = /DocumentRoot/uploads/tmp/ 

(4) Ausfuhrbare exteme Programme 

Von PHP-Skripten koimen beliebige weitere PHP-Skripte oder Programme aufgeru- 
fen werden. Um Manipulationen vorzubeugen, sollten die zur eigentlichen Applikati- 
on gehorenden Programme nur aus einem definierten Verzeichnis gelesen werden 
konnen: 

openbasedir = /ProgramRoot/execphp/ 

safe_mode = On 

saf e_mode_exec_dir = /ProgramRoot/execphp 

Zusatzlich konnen bestimmte Funktionen deaktiviert werden. Insbesondere 
phpinf o ( ) und show_source ( ) sind auf einem produktiven System normalerweise 
nicht erforderlich: 

disable_functions = system, exec, shell_exec, passthru, 

phpinfo, show_source, popen, proc_open 

(5) Sessions absichem 

In der Grundeinstellung verwaltet PHP die Sessiondaten in Dateien, deren Name die 
SessionID ist. Gespeichert werden diese Dateien unter /tmp in UNIX bzw. \temp 
unter Windows. Ublicherweise ist das Verzeichnis unter /tmp ungeschiitzt (Ver- 
zeichnis fur jedermaim schreibbar, Dateien gegebenenfalls fiir jederman lesbar). PHP 
selbst vergibt zwar sehr restriktive Zugriffsrechte fur diese Dateien (nur der Eigentii- 
mer darf lesen und schreiben), was aber in der Praxis unzureichend ist, da jeder Zu- 
griff via Webserver genau mit diesem Benutzer erfolgt. Um das Risiko der Datenma- 
nipulation und/oder Datenausspahung zu minimieren, muss dieses Verzeichnis gean- 
dert werden. AuBerdem ist die Zeit, fiir die eine Session gultig ist, zu reduzieren, 
etwa 1 Stunde (Standard ist 1 Tag): 

[sessions] 

session . savepath = /ProgramRoot/conf 

session. save handler = files 
session . gc_maxlifetime= 60 

Sessions konnen welter abgesichert werden indem man den Cookie-Namen andert, 
die Cookies restriktiver setzt (Host, Path) und die Giiltigkeitsdauer der Cookies limi- 
tiert: 

session. name = CookieName 

session . cookie secure = On 
session . cookie_lifetime = 3600 
session . use_trans_sid = On 

session . cookie_path = /sicher-anwendung/ 
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Bemerkungen 



session . cookie_domain = www.unternehmen.tld 

session . cache expire = 60 
session . cache limiter = nocache 

(6) Datenbankanbindung 

Wird mit PHP auf eine Datenbank zugegriffen, dann sind auch diese Einstellungen 
sicher zu konfigurieren: 

[PHP] 

mysql . def ault_host = sqlhost 

mysql . def ault_port = 3306 

mysql . def ault_socket = /pf ad/zu/mysqlsock 

mysql . def ault_user = wwwsql 

mysql . def ault password - sicher 

mysql. trace mode = Off 

(7) Eingabedaten maskieren 

Die Einstellung magic_quotes_gpc=on bewirkt, dass in der PHP-Umgebung alle 
problematischen Anfiihrungszeichen und Hochkomma mit einem vorangestellten 
Backslash versehen werden: 

[PHP] 

magic_quotes_gpc = On 

Achtung: diese Einstellung schiitzt nicht vor XSS und SQL-Injection, sic schiitzt nur 
das PHP-Skript selbst. 



Allgemein gilt: alle Werte (Pfadnamen, Timeout) in obigen Beispielen sind dem Ein- 
satz entsprechend anzupassen. Die obigen Beispiele beziehen sich auf eine einzelne 
php . ini, welche fur genau einen Webserver ohne "virtual Hosts" benutzt wird. Ins- 
besondere in Virtual-Host-Umgebungen (z.B. in der Kombination Apache und PHP) 
sind die Einstellungen in php . ini nicht ausreichend. Fiir Apache mit mod_php bietet 
sich dafiir z.B. die php_admin_vaiue^ Directive in httpd. conf an. 

(2) In der Anwendung sollte gepriift werden, ob fiir variabies_order zusatzlich 
auch noch g - GET und/oder c - Cookie gesetzt wird. 

(4) Das alleinige Setzen von saf e mode=On ist aufgrund bekannter Probleme in der 
Implementierung von PHP nicht ausreichend. AuBerdem kann saf e_mode=on zu 
weiteren Problemen mit den Dateiberechtigungen fiihren (z.B. wenn der Besitzer der 
Datei nach einem FTP-Upload nicht der des Webservers ist). saf e mode sollte also 
immer zusatzlich mit open_basedir abgesichert werden. Ebenso sollte man in 

saf e mode exec dir keine allgemeinen Pfade wie z.B. /usr/bin eintragen. In dem 
durch saf e mode exec dir refcrenzicrten Verzeichnis diirfen wirklich nur genau 
die Programme liegen, die von der Webanwendung gebraucht werden. 

(5) PHP speichert Session-Daten zunachst in normalen Dateien. Altemativ kann PHP 
auch andere Methoden dafur verwenden. Hierfur ist in php . ini die Einstellung 
session . save_handier=user zustandig. Details dazu, Z.B. zuT Verwendung einer 
SQL-Datenbank, sind in der Dokumentation von PHP zu finden. 

Die zusatzlichen Schritte miissen mit den Mafinahmen M170, insbesondere M 170.2, 
M170.3, M170.5 und M170.7, abgestimmt werden und stellen hier nur beispielhafte 



^ Achtung: php_admin_valuc kann nicht alle Konfigurationsvariablcn bcsctzcn 
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Empfehlungen dar. 

(6) Gelegentlich wird empfohlen, die fur die Datenbankanmeldung notwendigen An- 

meldedaten (Benutzemame und Passwort) nicht in den PHP-Skripten selbst, sondem 
in den Umgebungsvariablen des Webservers zu hinterlegen (z.B. PHP Cookbook). 
Beide Methoden haben Vor- und Nachteile. Die Umgebungsvariablen sind z.B. mit 
phpinf o ( ) sichtbar, die Daten im PHP-Skript selbst konnten gegebenenfalls iiber 
andere Schwachstellen erreicht werden. Die Hinterlegung der Anmeldedaten 

(mysql . default_user, mysql . def ault_password) inphp.ini ist daher ein guter 

Kompromiss, wenn man die anderen MaBnahmen bzgl. der sicheren Konfiguration 
dieser Datei (z.B. M350) beachtet. 

Prinzipiell vorteilhaft ware die Speicherung der Aimieldedaten in der Konfigurati- 
onsdatei des Webservers (z.B. http . conf), die nur von root/administrator lesbar 
sein sollte. Der Webserver wiirde dann eine persistente Verbindung zum Datenbank- 
server aufbauen. AUerdings ist fur PHP keine entsprechende Losung bekannt. Man 
kann jedoch mit der Directive php admin_vaiue in der httpd. conf bestimmte PHP- 
Konfigurationsvariablen belegen. 

(7) Diese Einstellung entbindet nicht davon, auf Data Validation (siehe M100 bis 
M150) zu achten. 
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2.32 M400 Serverkonfiguration: Web Application Isolation 

Abstract Auf jedem Rechner soUte genau ein Web- Oder Application- oder Datenbank- 

server laufen. 

Ebene System 

Beschreibung 

Jede Anwendung soUte unter ihrer eigenen Benutzerkennung laufen (vgl. M340). 
Trotzdem kann eine Schwachstelle in nur einer Anwendung alle anderen Anwendun- 
gen auf dem System mit gefahrden. 

Wird hingehen jede Webanwendung auf einem eigenen Rechner realisiert, kann man 
von Web Application Isolation sprechen. 

Beispiele 

Eine Webanwendung bestehend aus Web-, Application- und Datenbankserver wird 
auf 3 Rechner verteilt. Die einzelnen Konfigurationen unterscheiden sich nicht von 
denen in den MaBnahmen IVI370, M340, M350, M380, M390. Weitere Beispielkonfi- 
gurationen finden sich in [16] bis [20]. 

Bemerkung 

Die erhohte Sicherheit wird durch einen erhohten Aufwand fiir Konfiguration der 
einzelnen Rechner und evtl. zusatzliche Konfiguration auf der Firewall erkauft. Im 
konkreten Anwendungsfall sind die zusatzUchen Aufwande in Relation zum Sicher- 
heitsgewinn zu setzen. 
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2.33 M405 Vermeidung einer zu hohen Fehlertoleranz 

Abstract Vermeidung einer zu hohen Fehlertoleranz 

Ebene Implementierung 

Beschreibung 

Webentwickler tendieren dazu, Anwendungen zu tolerant gegeniiber Fehlem auszu- 
legen. So z.B. wird ein Programm mit Zusatzfutiktionen zur Behandlung von Fehler- 
zustanden ausgestattet, obwohl die Ursache dieser Fehlerzustande nicht voUstandig 
geklart ist. Zu den prinzipiell moglichen Fehlerursachen zahlen sowohl eigene Pro- 
grammierfehler, als auch jane Probleme, die aus dem oft komplexen Zusammenspiel 
von Server, Browser und Netzwerkarchitektur entstehen. Fehlerzustande konnen 
aber auch aus absichtlich manipulierten Eingabedaten resultieren (vgl. M120). 

Fine korrekt programmierte Webanwendung sollte robust und fehlertolerant gegen- 
iiber bestimmungsgemaBer Bedienung sein, die Session aber invalidieren, wenn ein 
offensichtlicher oder vermuteter Missbrauchsversuch vorliegt. 
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2.34 M410 Verschiedene MaBnahmen 



Abstract 



Hier werden verschiedene EinzelmaBnahmen und Best Practices zusammenge- 
fasst. 



Beschreibung 



M410.1 



Signierte Werte 



Wenn die Anwendung Werte an den Browser sendet, die dieser nicht verandem darf 
(z.B. in Auswahllisten, SessionID), die aber mit einem Form-Request wieder zur An- 
wendung zuriickkommen, dann muss die Anwendung die erhaltenen Werte mit Data 
Validation auf giiltige Werte priifen. 

Sollen die eigentlichen Werte zusatzlich vor Ausspahen geschiitzt werden, so emp- 
fiehlt sich die Verwendung von signierten Hashes anstatt der "Klartext" -Werte. 

Die folgenden Beispiele zeigen, wie man z.B. eine SessionID als Hidden-Field trans- 
portiert*". 

Beispiel in Perl 

Variable erzeugen und in die Ausgabe schreiben: 

$id = "grosse Zufallszahl darf nicht manipuliert werden"; 

$salt = "und noch ein Geheimnis dazu"; 

$hash = Digest: :MD5 : :md5_base64 ($salt. $id) ; 

print '<input type="hidden" name="sid" value=" ' . $hash . ' " />'; 

Variable eines Requests priifen: 

$id = "grosse Zufallszahl darf nicht manipuliert werden"; 
$salt = "und noch ein Geheimnis dazu"; 
$hash = md5 ($salt . $id) ; 

$sid = validatelnput ($q->param ( ' sid' ) ; 
if ($hash == $sid) { 

# welter 
} else { 

print ' Daten manipuliert.'; 

exit (1) ; 

} 

Beispiel in PHP 

Variable erzeugen und in die Ausgabe schreiben: 

$id = "grosse Zufallszahl darf nicht manipuliert werden"; 

$salt = "und noch ein Geheimnis dazu"; 

$hash = md5 ($salt . $id) ; 

print '<input type="hidden" name="sid" value=" ' . $hash . ' " />'; 

Variable eines Requests priifen: 

$id = "grosse Zufallszahl darf nicht manipuliert werden"; 

$salt = "und noch ein Geheimnis dazu"; 

$hash = md5 ($salt. $id) ; 

$sid = validatelnput ($_REQUEST [ 'sid' ]) ; 



Einc crfordcrlichc Input Data Validation ist durch validatcInpiitO liicr niir angcdcutct 
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if ($hash == $sid) { 

// weiter 
} else { 

print ' Daten manipuliert . ' ; 

exit (1) ; 



M410.2 



Perl tainted mode 



AUe Perl CGIs sollten im tainted mode (Option -T) betrieben werden. Der tainted 
mode ist zwar kein genereller Schutz vor gefahrlichen Parametem und Zeichen, aber 
Perl markiert damit zur Laufzeit des CGI-Skripts alle Parameter, die an Systemfunk- 
tionen iibergeben werden und erzwingt, dass diese explizit gepriifit werden miissen. 

In Apache mit mod peri kaim der tainted mode auch standardmaBig in der 
httpd. conf eingestellt werden: 

PerlWarn On 

PerlTaintCheck On 
PerlModule strict 



M410.3 



Server Side Includes in Apache absichern 



Wir verweisen auf die Quelle [21] "Apache Tutorial: Introduction to Server Side In- 
cludes". 



M410.4 



Sicherheitskritische Bereiche zusatzlich absichern 



Bevor einem bereits eingeloggten Benutzer Zugang zu besonders vertraulichen In- 
formationen oder sicherheitskritischen Bereichen einer Webanwendung gewahrt 
wird, soUte eine emeute Passwort-Abfrage stattfmden. Dadurch kann eine gleichzei- 
tige Kompromittierung des sicherheitskritischen Bereiches verhindert werden. 



M410.5 



Vertrauliche Informationen nicht anzeigen 

Zusatzlich zu M41 0.4 sollte die Webanwendung Vorkehrungen fiir den Fall einer 
Kompromittierung treffen. Sensible Informationen wie Passworter sollten daher ge- 
nerell nicht angezeigt werden. 
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2.35 M420 Einsatz von Web Application Security Tools 

Abstract Neben dem Einsatz von WebShields als Application-Firewalls sollten insbeson- 

dere auch Web-Scanner zum gezielten Aufdecken bestehender Schwachstellen 
in Webanwendungen zur Anwendung kommen. 

Ebene System 

Beschreibung 



2.35.1 WebShields 

Wahrend auf Netzwerk-Ebene mittlerweile ausgereifte Firew^all-Technologien zur 

Verfugung stehen, gab es auf der Ebene der Webanwendungen lange Zeit keinen 
vergleichbaren Schutz. Die jetzt existierenden WebShield-Produkte haben ihre erste 
Erprobungsphase nun hinter sich. 

WebShields konnen auch als Web Application Firewall bezeichnet werden. Sie fil- 
tem den Datenstrom zwischen Browser und Webanwendung. Tritt ein als unzulassig 
eingestuftes Eingabemuster auf, wird der Transfer unterbrochen oder auf eine ande- 
re, vorher festgelegte Weise reagiert. Ein WebShield arbeitet als Proxy im Daten- 
strom, kennt somit das Protokoll der Anwendung. 

Grundsatzlich filtem WebShields die vom Browser an den Webserver iibertragenen 
Daten. Einige WebShield-Produkte sind zusatzlich in der Lage, die vom Webserver 
an den Browser versandten Daten zu iiberwachen. Hierbei kann das WebShield "ler- 
nen", wie die Daten beschaffen sind. Dadurch wird ein spaterer Vergleich zwischen 
aktuellen und gelemten Daten ermoglicht. So konnen Filter in eingeschranktem 
MalJe verhindem, dass der Browser schadhaften Code erhalt (z.B. von einer Weban- 
wendung, die keine ausreichende Output-£)ato Validation, siehe M100, durchflihrt). 

WebShields sind nicht in der Lage, alle Angriffsformen auf Webanwendungen zu er- 
kennen. Generell gilt: Sicherheitsprobleme sollten in der Webanwendung selbst ge- 
lost werden. WebShields sollten als zusatzliche SchutzmaBnahme in Betracht gezo- 
gen werden insbesondere fiir folgende Falle: 

• In vielen Untemehmen werden Webanwendungen von einer Vielzahl extemer 
Partner entwickelt. Die Sicherheit liegt in den Handen der extemen Partner. 

• Bei bestehenden Anwendungen ist ein nachtragliches Security-Review bzw. ein 
Beheben von Sicherheitsproblemen in der Anwendung haufig gar nicht moglich, 
sei es aus Kostengriinden oder well die Entwickler nicht mehr verfugbar sind. 

• Die Absicherung iiber mehrere Sicherheitsstufen ist ein wesentliches Prinzip fiir 
hohere Sicherheit (Second Line of Defense). WebShields leisten dabei gute 
Dienste. 

WebShields in der IT Infrastruktur 

WebShields sind Komponenten in der IT-Infrastruktur, die weniger leicht als bei- 
spielsweise Netzwerk-Firewalls zu integrieren sind. Die Lastanforderungen (Perfor- 
mance-EinbuBen durch permanente Priifung des Datenverkehrs) und die Abhangig- 
keiten zu anderen Systemen, wie Loadbalancem, Proxys und Cluster- Architekturen, 
sind deutlich grofier. 
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Die aktuell verfugbaren Produkte weisen einen unterschiedlichen Funktionsumfang 
auf. Dieser reicht vom einfachen Filtem unzulassiger Zeichen bis bin zu komplexen 
Systemen, die versuchen, die Anwendungslogik (zumindest teilweise) zu verstehen. 
Generell unterscheiden lassen sich Software-WebShields, Appliances, Webserver- 
spezifische Produkte, und sonstige. Wahrend ein Software- WebShield als reines 
Softwareprodukt auf vorhandener Hardware zzgl. Betriebssystem installiert werden 
muss, bezeichnet eine WebShield- Appliance eine als Produkt erhaltliche Kombinati- 
on aus Hard- und Software. Zu den Webserver-spezifischen Produkten zahlen auch 
die frei verfugbaren Tools "mod secvirity" und "Brute Watch": 

modsecurity 

Eine besondere Stellung unter den Filtern nimmt das frei verfiigbare mod_security 
fur Apache ein. mod security ist ein Input-Filter, der mit Regeln ausgestattet werden 
kann. So kann mod security z.B. XSS, SQL-Injection, Null-Byte oder Path Traver- 
sal erkennen und entsprechend reagieren. Mit den "Advanced Filtering" genannten 
Techniken kann selektiv auf bestimmte URLs oder auf bestimmte Werte im HTTP- 
Header reagiert werden. Es ist moglich, eigene, exteme Programme aufzurufen, wo- 
mit die Funktionalitat fast beliebig erweitert werden kann. 

Eine beispielhafte Konfiguration in httpd. conf , die den oben genannten Funktions- 
umfang hat, ware: 

SecFilterEngine On 
SecFilterCheckURLEncoding On 
SecFilterForceByteRange 32 126 
SecAuditEngine RelevantOnly 

SecAuditLog /ServerRoot/logs/ secaudit_log 

SecFilterScanPOST On 

'deny, log, status : 406 
'\.\./" 
'/\.$" 
'<(. l\n)+>" 
'\" [ [ :space: ] ] *>" 
' ' [ [: space : ] ] *>" 

'HTTP_CONTENT_TYPE" multipart/form-data 



SecFilterDef aultAction 

SecFilter 

SecFilter 

SecFilter 

SecFilter 

SecFilter 

SecFilter Selective 



Perl Module Apache: :Brute Watch 

Das Perl-Modul Apache: :BruteWatch iiberwacht die Authentisierung des Webser- 
vers (Basic Authentication). Es greift ein, wenn mit Brute-Force-Angriffen versucht 
wird, Passworter herauszufinden. Apache selbst (bis einschl. Version 2.0.50) hat kei- 
ne eigene Moglichkeit, dies zu verhindem. 

Bei Verwendung von Apache: :Brute Watch ist zunachst eine Tabelle in einer Daten- 
bank anzulegen, auf die Apache daim Zugriff hat, z.B. fur MySQL: 



CREATE TABLE bruteattempt ( 

id INT (11) NOT NULL auto_increment, 

ts INT (11) DEFAULT NULL, 

username VARCHAR(255) DEFAULT NULL, 

PRIMARY KEY (id) 
) TYPE=MyISAM; 

CREATE TABLE brutenotif ied ( 

id INT (11) NOT NULL auto_increment, 

username VARCHAR(255) DEFAULT NULL, 

ts INT (11) DEFAULT NULL, 

PRIMARY KEY (id) 
) TYPE=MyISAM; 

INSERT INTO db VALUES ( ' FQDN ' , 'brutelog', 'user', 

'Y','Y','Y','Y','Y','N','N','N','N','N'); 
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Dann wird Apache: :Brute Watch in der httpd . conf konfiguriert: 



PerlLogHandler 
PerlSetVar BruteDatabase 
PerlSetVar BruteDataUser 
PerlSetVar BruteDataPassword 
PerlSetVar BruteMaxTries 
PerlSetVar BruteMaxTime 
PerlSetVar BruteForgive 
PerlSetVar BruteNotify 



Apache: :BruteWatch 
DBI : mysql : brutelog 
user 

password 

5 

120 
84600 

adminSserver . tld 



2.35.2 Web Scanner 

Web Scanner (oder: Web Application Scanner) sind Programme fiir Penetrations- 
tests. Sie untersuchen cine Anwendung auf bekannte Schwachstellen und unterstiit- 
zen dabei den Webentwickler oder Penetrations-Tester beim Auffinden von Sicher- 
heitsliicken. 

Funktionsweise 

Ein Web Scanner wird auf einem Client-Computer installiert, um dann die Weban- 
wendung zu analysieren. Im Zuge der Analyse konnen folgende vier Phasen durch- 
laufen werden: 

Crawl/Scan 

Ein Web Scanner bewegt sich ahnlich wie cine Suchmaschine durch die gesamte 
Webanw^endung. Dabei w^erden samtliche Links besucht und gegebenenfalls Form- 
Felder mit Testwerten ausgefiillt. Der Scanner erhalt so ein umfassendes Wissen 
liber den Aufbau der Webanwendung, die Funktionsweise von Dialogschritten und 
den Inhalt von Formular-Seiten. 

Die Webanwendung wird auf haufig vorhandene Installations-, Konfigurations- oder 
Testverzeichnisse, sowie bekannte problematische oder informative Dateien durch- 
sucht (Stichworter: Directory Enumeration, File Enumeration, Directory Traversal, 
Forceful Browsing). 

Unterstiitzt werden kann die Scan-Phase durch Einbeziehen groBer offentlicher 
Suchmaschinen. Vorausgesetzt wird hierfur, dass die eigene Website bereits durch 
diese Suchmaschinen indexiert worden ist. Die Ergebnisse dieses Schrittes vmrden 
dann auf den Suchmaschinen gespeichert (Index/Cache). Im Rahmen einer Scan- 
Phase konnen diese Suchmaschinen nun gezielt nach Informationen iiber die eigene 
Website abgefragt werden. Fiir die Zusammenstellung von Suchmustem, sowie Au- 
tomatisierung der Abfragen kaim die Nutzung spezieller Tools zweckmaBig sein. 

Analyse 

In einem nachsten Schritt wird die Webanwendung einer eingehenden Sicherheits- 
analyse unterzogen. Die gewonnenen Erkenntnisse konnen in einer Datenbank hin- 
terlegt werden: Typ und Version des Webservers, verwendete Technologien und 
Tools (CGI, Servlets, JSP, JavaScript, PHP, usw.), Verwendung von Cookies oder 
anderer Mechanismen zum Session-Tracking, Analyse der Form-Parameter einer 
Seite, insbesondere auch die Verwendung von Hidden-Parametem, Extraktion von 
Kommentaren. 

Audit/Penetrationstest 

Unter Einbeziehung des in der vorangegangenen Phase gewonnenen Wissens werden 
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systematisch fehlerhafte oder unzulassige Eingabemuster erzeugt, und an die We- 
banwendung versandt. Einige der existierenden Scanner unterteilen diese Phase in 
eine schadlose, und eine potentiell schadhafte Priifung. 

Reporting 

Die Ergebnisse der Scan- und Audit-Phase werden in Reports zusammengefasst. Der 
Umfang reicht dabei von Executive Summeries mit Nennung nur der groBten 
Schw^achstellen bis hin zu detaillierten Beschreibungen, in denen auch erste Hinw^ei- 
se fur die Behebung des jeweiUgen Problems gegeben werden konnen. 

Der Nutzen von Web Scannern 

Allgemein gilt: Web Scanner sind sinnvolle Tools, um Experten bei der Analyse der 
Sicherheitseigenschaften einer Webanwendung zu unterstiitzen. Sie sind jedoch we- 
der in der Lage, fehlendes Know-how zu kompensieren, noch konnen sie Experten 
ersetzen. Die einer Webanwendung innewohnende Komplexitat und die Tatsache, 
dass manche Schwachstellen von einem Tool grundsatzlich nicht erkennbar sind, ha- 
ben zur Folge, dass weiterhin geiibte Personen fiir den GroBteil der Analyse benotigt 
werden. Eine Interpretation eines Web-Scan-Reports ist ohne Erfahrung im Testen 
von Webanwendungen nur schwer moglich. 
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%-Encoding 

Adaptive Proxy 
Anwender 



Synonym fur URL-Encoding. Kodierung von Sonderzei- 
chen in der URL mit %xx. 

friiher benutzter Begriff fur Application Level Firewall 
Person, die ein Programm oder eine Applikation benutzt.. 



Application Level Firewall Firewall die den Datenstrom auf der Applikations- 

ebene (OSI Level 7) kontroUiert; siehe auch WebShield 



Applicationserver 

Bedrohung 
Benutzer 

Benutzerkennung 
Blacklist 
Brute Force 

Buffer Overflow 

Cache 

Code-Injection 

Command-Injection 

Content Branding 
Cookie-Injection 
Cookie Poisoning 
Cookie Tampering 
Countermeasure 
Cracker 

Credentials 



spezieller Dienst/Programm, welches komplexe Daten zur 
Verfiigung stellt 

potenzielle Gefahr fur Daten oder Systeme 

Person, die ein Programm, Applikation benutzt. Auch: 
Name einer Benutzerkeimung des Systems (z. B. aus 
/etc/passwd) 

siehe Benutzer 

Liste mit unerlaubten Zeichen, Worter, etc. 

Angriffstechnik, bei der mittels Durchprobieren aller Mog- 
lichkeiten Passworter etc. ermittelt werden 

spezielle Angriffstechnik auf Variablen (memory) 

"fliichtiger Zwischenspeicher" (zeitlich begrenzt) 

einschleusen von HTML-Code durch die verwendete 
Skriptsprache auf dem Server, z. B. PHP (Variante von 
HTML-Injection) 

spezielle Angriffstechnik mit dem Ziel, Kommandos im 
System auszufuhren 

einheitliches Aussehen des Inhaltes 

spezielle Angriffstechnik auf Cookies 

Manipulation des Wertes eines Cookie 

siehe Cookie-Manipulation 

GegenmaBnahme 

Person, die mit unerwiinschten, kriminellen Mitteln ver- 
sucht, auf einem Computer Daten zu manipulieren oder zu 
stehlen 

Authentifizierungsdaten 



Cross-Site Scripting Manipulation von Parametem, so dass im Browser Skript- 

code ausgefiihrt wird; haufig auch synonym zu HTML-In- 
jection verwendet 
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Database Gesamtheit der Daten in einer Datenbank 

Data Validation Prufimg der Daten in Bezug auf Web Application Security 

Defacement Manipulation des Inhaltes einer Website 

Denial of Service Uberflutung / Die Webanwendung wird funktionsunfahig 

gemacht 

Directory Enumeration Erraten von Verzeichnisnamen durch systematisches 

Probieren 

Zugriff auf Verzeichnisse auBerhalb des DocumentRoot 

Verzeichnis, in dem sich die Dokumente eines Webservers 
befinden 

siehe: Denial of Service 

Kodierung, im Gegensatz zu Encryption = Verschliisselung 
(eine Kodierung ist i. A. direkt umkehrbar) 

Verschliisselung, im Gegensatz zu Encoding = Kodierung 
(eine Verschliisselung ist nur mit einem Schliissel zu ent- 
schliisseln) 

Aufzahlung, Nummerierung (z. B. von Dateien), systema- 
tisches Probieren. Siehe auch 'Brute Force' 

Umgebungskontext, in dem ein Programm gestartet wird 
(insbesondere die Environmentvariablen) 

Synonym fur %-Encoding 

konkrete Ausnutzung einer Schwachstelle, zumeist in 
Form eines kleinen Programms oder Skripts, das mit wenig 
Vorkeimtnissen genutzt werden kann 

Direkter Zugriff auf eine URL (unter Umgehung der Ap- 
plikationslogik) 

tatsachlich bestehende Moglichkeit, dass Schaden entsteht 

Person, die Schadfunktionen, Gefahren und Bedrohungen 
aufzeigt, diese aber im Gegensatz zum Cracker nicht (kri- 
minell) ausnutzt 

Hidden Field-Manipulation Anderung von Hidden-Parametem 

HIDDEN-Parameter spezieller Parameter in einer Webseite, welcher fiir den 

Anwender normalerweise nicht sicht-/anderbar ist 

Horizontal Privilege Escalation Rechte eines anderen Benutzers oder Ver- 

zeichnisses konnen erlangt werden 

HTML-Encoding Umwandlung eines Zeichens zum HTML-Entity 

HTML-enkodiert String (Text), der ein HTML-Entity reprasentiert 

HTML-Escape %-Encoding im HTML Text 



Directory Traversal 
DocumentRoot 

DoS 

Encoding 
Encryption 

Enumeration 

Environment 

Escape-Encoding 
Exploit 

Forceful Browsing 

Gefahrdung 
Hacker 
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HTML-Injection Einschleusen von HTML-Code (Variante von, aber im Ge- 

gensatz zu Cross-Site Scripting) 

HTTP Response Splitting spezielle Angriffstechnik zur Manipulation des HTTP 

Header 

Identity Theft Diebstahl von personlichen Daten/Merkmalen (z. B. Pass- 

wort) 

Information Disclosure Verletzung der Vertraulichkeit, Mithoren, Ausspionie- 

ren 

Information Gathering Informationsbeschaffung 

Input Validation Data Validation bezogen auf Eingabedaten zur Web- 

applikation 

Malicious Code jede Form von unerwiinschten Daten 

Malware Oberbegriff fur jede Form von unerwiinschter oder storen- 

der Software 

Named Character Reference Synonym fiir HTML-Encoding mit benamten 

Symbolen (Terminologie des W3C) 

Numeric Character References Synonym fiir HTML-Encoding mit nume- 

rischen Symbolen (Terminologie des W3C) 

Output Sanitation Synonym fiir Output Validation 

Output Validation Data Validation der Ausgabe der Daten zum Browser oder 

zu anderen Servem 

Parameter-Manipulation Manipulation von Parametem (Name und/oder Wert) 

Parameter Tampering siehe Parameter-Manipulation 

Path Traversal Spezielle Angriffstechnik. Siehe Directory Traversal 

Penetrationstest Uberpriifiing einer Applikation (insbesondere mit fehler- 

haften Eingaben) 

Percent-Encoding siehe %-Encoding 

Predictable Resource Locations vorhersagbare Resourcen, siehe auch Di- 
rectory Enumeration 

Privilege Escalation fehlerhafte Erhohung oder Verschiebung von Privilegien, 

Zugriffrechten 

rc-Skript spezielles Skript zum Starten eines Dienstes 

Referer spezielle Variable im HTTP-Header (die Schreibweise ist 

nicht korrekt, sie wird hier nur verwendet, wenn genau die- 
se Variable gemeint ist, sonst siehe 'Referrer') 

Referrer URL der Seite, von der aus verlinkt wurde 

Sandbox spezielle, eingeschrankte Umgebung fiir 

Dienst/Programm/Skript 
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Scanner 

ServerRoot 

Session 

SessionID 

Server 

Session Fixation 
Session-Injection 



allgemeine Bezeichnung fiir ein Programm, welches Infor- 
mationen durch systematische Tests sammelt; siehe auch 
Webscaimer 

Verzeichnis, in dem die Software fur einen Server instal- 
liert ist 

logische Verbindung zwischen Client und Server; kann 
iiber mehrere Einzel-Zugriffe hinweg bestehen 

eindeutiger Bezeichner fiir eine Session (diese Schreibwei- 
se wird benutzt, wenn der Wert gemeint ist, der eine Sessi- 
on eindeutig identifiziert, z. B. in einem Cookie) 

damit ist immer ein Computer mit installiertem Betriebs- 
system und evtl. installierten Programmen gemeint 

spezielle Angriffsmethode 

siehe Session Fixation 



Shell Command-Injection siehe Command-Injection 



(Web-)Shield 
Skript 

Social Engineering 

Spidering 

SQL-Injection 

SSI-Injection 



Firewall auf Applikationsebene 

Programm, das in einer Interpretersprache geschrieben ist 

Missbrauch eines Vertrauensverhaltnisses zum Erschlei- 
chen von (personlichen) Informationen 

alle URLs einer Webapplikation aufsammeln 

spezielle Angriffsmethode auf Datenbanken 

spezielle Angriffsmethode auf dynamische Webseiten (mit 
SSI) 



Stealth Commanding Synonym fur Command-Injection 



Unicode 
URL-Encoding 
URL-enkodiert 
URL-Escape 



Standard fiir multilingualen Zeichensatz 
Umwandlung eines Zeichens als %-Encoding 
String (Text) der ein Zeichen in %-Encoding reprasentiert 
%-Encoding in URL 



Vertical Privilege Escalation fur den aktuellen Benutzer oder das aktuelle Ver- 
zeichnis konnen weitere Rechte erlangt werden 



Vulnerability 
War Googling 
War Searching 



Verwimdbarkeit, Angriffspunkt, Schwachstelle 
siehe War Searching 

automatisiertes Auffinden von Schwachstellen in Websites 
mit Suchmaschinen 



Web Application Firewall siehe WebShield 
Web Application Shield siehe WebShield 



3.2 Glossar 



Webanwendung 



Synonym fiir Webapplikation 



Web Application Isolation Trennung von Daten und Prozessen/Threads einer 

Webanwendung 



Webapplikation 

Webformular 
Web Scanner 
WebShield 
Webserver 

Webservice 



Programm oder Gruppe von Programmen, die zusammen 
eine Anwendung realisieren die mittels eines Webservers 
bedient wird 

Formular, das sich auf einer Webseite befindet 

Programm zum Testen einer Webapplikation 

Application Level Firewall, die einen Webserver schiitzt 

Dienst/Programm, welches via HTTP Daten zur Verfiigung 
stellt 

Dienst, der mit XML-formatierten Meldungen iiber HTTP 
kommuniziert 



Website 

Website-Spoofing 
Webspace 
Whitelist 
WS-Security 



alle Seiten, die ein Webserver zu einer Domain liefert 
Falschung einer Website oder Webseite 
Platz (auf Festplatte), den eine Website benotigt 
Liste mit erlaubten Zeichen oder Zeichenketten 
siehe Web Service Security 
Web Service Security Sicherheit fiir Web Services (XML, SOAP) 
Xpath-lnjection spezielle Angriffsmethode auf Pfade in XML 

XSS Akronym fiir Cross-Site Scripting 



Zugriffsrechte 



Berechtigungen (Permissions) fiir Dateien, Verzeichnisse 
oder Prozesse 



